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

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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 2221 bytes --]

On Tue, 2008-01-22 at 07:27 +0100, Eric Dumazet wrote:
> Zhang, Yanmin a écrit :
> > On Tue, 2008-01-22 at 13:24 +0800, Zhang, Yanmin wrote:
> >> On Mon, 2008-01-14 at 09:46 -0800, Rick Jones wrote:
> >>>>> *) netperf/netserver support CPU affinity within themselves with the 
> >>>>> global -T option to netperf.  Is the result with taskset much different? 
> >>>>>   The equivalent to the above would be to run netperf with:
> >>>>>
> >>>>> ./netperf -T 0,7 ..
> >>>> I checked the source codes and didn't find this option.
> >>>> I use netperf V2.3 (I found the number in the makefile).
> >>> Indeed, that version pre-dates the -T option.  If you weren't already 
> >>> chasing a regression I'd suggest an upgrade to 2.4.mumble.  Once you are 
> >>> at a point where changing another variable won't muddle things you may 
> >>> want to consider upgrading.
> >>>
> >>> happy benchmarking,
> >> Rick,
> >>
> >> I found my UDP_RR testing is just loop in netperf instead of ping-pang between
> >> netserver and netperf. Is it correct? TCP_RR is ok.
> >>
> >> #./netserver
> >> #./netperf -t UDP_RR -l 60 -H 127.0.0.1 -i 30,3 -I 99,5 -- -P 12384 -r 1,1
> > I digged into netperf and netserver.
> > 
> > netperf binds ip 0 and port 12384 to its own socket. netserver binds ip
> > 127.0.0.1 and port 12384 to its own socket. Then, netperf calls connect to setup server
> > 127.0.0.1 and port 12384. Then, netperf starts sends UDP packets, but all packets netperf
> > sends are just received by netperf itself. netserver doesn't receive any packet.
> > 
> > I think netperf binding should fail, or netperf shouldn't get the packet it sends out, because
> > netserver already binds port 12384.
> > 
> > I am wondering if UDP stack in kernel has a bug.
> 
> If :
> - socket A is bound to 0.0.0.0:12384 and
> - socket B is bound to 127.0.0.1:12384
> 
> Then packets sent to 127.0.0.1:12384 should be queued for socket B
> 
> If they are queued to socket A as you believe it is currently done, then yes 
> there is a bug in kernel.
I double-checked it and they are queued to socket A. If I define a different local port
for netperf, packets will be queued to socket B.

-yanmin