fix to util_sock.c

[Kenichi Okuyama]

Dear Jeremy and all,

Since system reported that I failed in sending, I'll re-send the
message again, sorry if you had this twice.

>>>>> "JA" == Jeremy Allison <jeremy at valinux.com> writes:
>> By the way, If buggy target is KNOWN, or if non-buggy target is
>> KNOWN, then we can always switch it back to read() by used something
>> like:
>> 
>> #ifdef HAVE_WORKING_RECV
>> #define   RECV(a,b,c,d)  recv(a,b,c,d)
>> #else
>> #define RECV(a,b,c,d)   read(a,b,c)
>> #endif
>> 
>> kind of macro.
>> 
>> And by defining HAVE_WORKING_RECV as default, we can always
>> find one who's not working.
JA> This is only worthwhile if we have evidence that changing to 
JA> use recv() gives us an advantage (maybe performace) of some kind.
JA> Otherwise, why change it ? It doesn't seem cleaner than read()
JA> and it doesn't give a performace advantage that we can measure.

You must be aware of WHAT you are measuring.

As I mentioned with patch, the patch will not effect SAMBA's
performance. But this is because samba will not start treating
request until LAST packet arrive.

While waiting for the packet, there's two way of doing this.
One is like original, you jump back and forth between user space
and kernel space every time TCP/IP packet arrive. Second, is to
let kernel wait for entire packet, telling not to come back till
everything is recieved.


This will effect SYSTEM LOAD, and that of CRITICAL TIMING.
If you have enought CPU resource, you'll see no difference.
If you are too far from what's being required to run stable,
you'll see no difference, too.


And in ether cases, what you need is patched kernel that will
reports internal, recoverable, errors, Which I have.

As I already mentioned, 500k call of read() against socket, became
370k calls of recv(). As result, we did not gain any performance for
Samba. This also did not gain any performance for kernel, because
CPU was already fully being used, and required more.

What's being changed was, that kernel now can put ethernet driver
recieving packet to TCP read buffer more quickly. And as result,
while original samba caused 'TX FIFO ERROR!' ( this is error message
from AMD ethernet chip driver, meaning that kmalloc for creating new
area for recieving packet failed. And this also means packet drop
occured at ethernet driver level ), this patched one will not cause
this error anymore.

This is something of REALTIME-ABILITY. This will not effect average,
so this will not come with any differenciation on BENCHMARK, which
measures AVERAGE.

# If you want to see the difference, you can see it with OVERLOADED
# server. If you run, for example, netbench with too many clients,
# you'll find that clients will have different ending time, and as
# number of client increases, this ending time disperse.
# With patched samba, this diperse amount will be smaller, like
# it is with small enough number of clients.



>> # I experenced read() that did not work for socket more oftenly than
>> # non working recv(), is the reason.
JA> The experience of Samba on all the supported platforms
JA> has been the reverse. Can you be specific on which platforms
JA> read() on sockets is broken ? I have never come accros such
JA> a platform.


Mainly embedded OS. VxWorks( about 4 years ago ), PhenixOS( about 5
years ago ), internal (IBM internal, I mean ) embedded OSes (
including one I made my self (T-T)), AIX for i386 version 1.2... if
I remember right ( was fixed at 1.2.1 ) about 9 years ago.

I don't know about AIX for Power Architectures, for I learned a lot
about AIX with i386 version, I never coded using read() for socket.

# And, that by using MSG_WAITALL, I helped lots of SYSTEM
# stability.


best regards,
---- 
Kenichi Okuyama, Tokyo Research Lab, IBM-Japan, Co.