RE: TCP stream performance regression due to c377411f2494a931ff7facdbb3a6839b1266bcf6

[Eric Dumazet <eric.dumazet@gmail.com>]

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
>