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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 22 Jan 2008 14:52:32 +0800
From:	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>
To:	Eric Dumazet <dada1@...mosbay.com>
Cc:	Rick Jones <rick.jones2@...com>, netdev@...r.kernel.org,
	David Miller <davem@...emloft.net>
Subject: Re: Netperf TCP_RR(loopback) 10%
	regression	in	2.6.24-rc6,	comparing with 2.6.22

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


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html