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]

Message-ID: <47958CC8.9060609@cosmosbay.com>
Date:	Tue, 22 Jan 2008 07:27:20 +0100
From:	Eric Dumazet <dada1@...mosbay.com>
To:	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.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

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.

> 
> TCP_RR testing hasn't such issue.
> 
> -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
> 
> 

--
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