TCP stream performance regression due to c377411f2494a931ff7facdbb3a6839b1266bcf6

TCP stream performance regression due to c377411f2494a931ff7facdbb3a6839b1266bcf6

[Alex,Shi]

In our netperf testing, TCP_STREAM56 shows about 20% or more performance
regression on WSM/NHM and tigerton machines. The testing boot up both
netserver and client on localhost. The testing command like this:
./snapshot_script_net TC_STREAM56 127.0.0.1 

We found the following commit causes this issue.
c377411f2494a931ff7facdbb3a6839b1266bcf6  
Revert this commit will recover this regression on all machine. 

Regards!
Alex 

RE: TCP stream performance regression due to c377411f2494a931ff7facdbb3a6839b1266bcf6

[Zhang, Yanmin]

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

More info about the testing:
It's a loopback testing. We start one client netperf process to communicate with netserver process in a stream TCP testing. To reduce the cpu cache effect, we bind the 2 processes on 2 different physical cpus.
#taskset -c 0 ./netserver
#taskset -c 15 ./netperf -t TCP_STREAM -l 60 -H 127.0.0.1 -i 50,3 -I 99,5 -- -s 57344 -S 57344 -m 4096

>>-----Original Message-----
>>From: Shi, Alex
>>Sent: 2010Äê6ÔÂ18ÈÕ 15:17
>>To: eric.dumazet@gmail.com; davem@davemloft.net
>>Cc: Chen, Tim C; Zhang, Yanmin; linux-kernel@vger.kernel.org
>>Subject: TCP stream performance regression due to
>>c377411f2494a931ff7facdbb3a6839b1266bcf6
>>
>>In our netperf testing, TCP_STREAM56 shows about 20% or more performance
>>regression on WSM/NHM and tigerton machines. The testing boot up both
>>netserver and client on localhost. The testing command like this:
>>./snapshot_script_net TC_STREAM56 127.0.0.1
>>
>>We found the following commit causes this issue.
>>c377411f2494a931ff7facdbb3a6839b1266bcf6
>>Revert this commit will recover this regression on all machine.
>>
>>Regards!
>>Alex

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

RE: TCP stream performance regression due to c377411f2494a931ff7facdbb3a6839b1266bcf6

[Eric Dumazet]

Le vendredi 18 juin 2010 à 16:26 +0800, Zhang, Yanmin a écrit :
> More info about the testing:
> It's a loopback testing. We start one client netperf process to communicate with netserver process in a stream TCP testing. To reduce the cpu cache effect, we bind the 2 processes on 2 different physical cpus.
> #taskset -c 0 ./netserver
> #taskset -c 15 ./netperf -t TCP_STREAM -l 60 -H 127.0.0.1 -i 50,3 -I 99,5 -- -s 57344 -S 57344 -m 4096
> 

Thanks guys

We corrected a proven vulnerability in network stack.

If you want better netperf results, just increase size of your sockets
buffers.  57344 is _very_ low for localhost communication, given lo MTU
is 16436.

As we also increased skb->truesize lately, you might also increase
buffer size regardless of this (net: sk_add_backlog() take rmem_alloc
into account) commit.

In my case, I saw following improvement :

Under huge stress from a multiqueue/RPS enabled NIC, a single flow udp
receiver can now process ~200.000 pps (instead of ~100 pps before the
patch) on a 8 core machine.

Thats a 200.000 % increase, in a situation no tuning was possible ;)


> >>-----Original Message-----
> >>From: Shi, Alex
> >>Sent: 2010年6月18日 15:17
> >>To: eric.dumazet@gmail.com; davem@davemloft.net
> >>Cc: Chen, Tim C; Zhang, Yanmin; linux-kernel@vger.kernel.org
> >>Subject: TCP stream performance regression due to
> >>c377411f2494a931ff7facdbb3a6839b1266bcf6
> >>
> >>In our netperf testing, TCP_STREAM56 shows about 20% or more performance
> >>regression on WSM/NHM and tigerton machines. The testing boot up both
> >>netserver and client on localhost. The testing command like this:
> >>./snapshot_script_net TC_STREAM56 127.0.0.1
> >>
> >>We found the following commit causes this issue.
> >>c377411f2494a931ff7facdbb3a6839b1266bcf6
> >>Revert this commit will recover this regression on all machine.
> >>
> >>Regards!
> >>Alex
>