Re: Netperf TCP_RR(loopback) 10% regression in 2.6.24-rc6, comparing with 2.6.22

["Zhang, Yanmin" <yanmin_zhang@linux.intel.com>]

On Wed, 2008-01-23 at 08:42 +0800, Zhang, Yanmin wrote:
> On Tue, 2008-01-22 at 10:36 -0800, Rick Jones wrote:
> > When parsing the -P option in scan_socket_args() of src/nettest_bsd.c, 
> > netperf is using "break_args()" from src/netsh.c which indeed if the 
> > command line says "-P 12345" will set both the local and remote port 
> > numbers to 12345.  If instead you were to say "-P 12345,"  it will use 
> > 12345 only for the netperf side.  If you say "-P ,12345" it will use 
> > 12345 only for the netserver side.  To set both sides at once to 
> > different values it would be "-P 12345,54321"
> > 
> > In theory, send_udp_rr() in src/nettest_bsd.c (or I suppose 
> > scan_socket_args() could have more code added to it to check for a UDP 
> > test over loopback, but probably needs to be a check for any local IP, 
> > and unless this becomes something bigger than "Doctor! Doctor! It hurts 
> > when I do this!" :) I'm inclined to leave it as caveat benchmarker and 
> > perhaps some additional text in the manual.
> I will instrument kernel to see if kernel does work like it is expected.
> 
> When an issue is found, we shouldn't escape by saying it's nothing to do
> with me.
> 
I went through netperf source again and did a step debug with gdb.

Both sides bind 0.0.0.0:12384 to its own sockets. netperf binds firstly.
When netperf calls connect to configure server 127.0.0.1:12384, kernel chooses
socket A's queue. kernel is correct.

Anther question is no matter who binds 0.0.0.0:12384 firstly, netperf
always sends packets to its own socket. I suspect API connect called by netperf to
configure server ip/port has the side-effect, as server doesn't call connect.

It's good to add additional text in netperf manual.

Sorry and thanks for your guys kind response.

-yanmin