netdev - Re: [RFC net-next-2.6] net: speedup sk_wake

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:	Wed, 07 Oct 2009 08:53:37 -0700
From:	Rick Jones <rick.jones2@...com>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	"David S. Miller" <davem@...emloft.net>,
	Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: [RFC net-next-2.6] net: speedup sk_wake_async()

Eric Dumazet wrote:
> Rick Jones a écrit :
> 
>>How about 64-bit?
> 
> 
> No data yet, but larger footprint unfortunatly :-(

True - nothing comes for free.  I'm not "in touch" with the embedded side, where 
I presume 32 bit will be if not already is now the primary bitness, but over in 
the server side of the world, at least the part I see, 64 bit is de rigeur, 
hence my curiousity.

>>Got any netperf service demand changes?
> 
> 
> I was going to setup a bench lab, with a typical RTP mediaserver, with say
> 4000 UDP sockets, 2000 sockets exchanging 50 G.711 Alaw/ulaw
> messages per second tx and rx. (Total : 100.000 packets per second each way)
> 
> Is netperf able to simulate this workload ?

Touche :)

It would be, well, cumbersome with netperf2, but possible.  One would 
./configure --enable-intervals and then run some variation of:

netperf -t UDP_STREAM -l <time> -H <remote> -b <burst size> -w <burst interval> 
-- -m <message size>

a large number of times.  Given the lack of test synchronization in netperf2 I 
probably would not try to aggregate the results of N thousand simultaneous 
netperf2 instances and would rely instead on external (relative to netperf) 
packet rate reports.

Still, if the cache miss removed is a non-trivial fraction of the overhead I 
would think that something like:

netperf -t UDP_RR -l <time> -I 99,0.5 -i 30,3 -c -C -H remote -- -r 4

run with and without the change would show a difference in the service demand, 
and if you hit the confidence intervals you would be able, per the above be 
confident in the "reality" of a CPU utilization difference of +/- 0.25% . 
Getting that test to that level of confidence probably means pinning the NIC 
interrupts to a specific CPU and then binding netperf/netserver on either side 
using the global -T option.

Barring getting sutiable confidence intervals, somewhere in the middle of all 
that would be ./configure --enable-burst and then, still with pinning and 
binding for "stability" something like:

netperf -t UDP_RR -l <time> -I 99,0.5 -i 30,3 -H <remote> -- -r 4 -b <burst>

to put multiple transactions in flight across that flow - choosing <burst> to 
take the CPU on which either netperf, netserver, or the interrupts are running 
to 100% saturation.  Here I left-off the CPU utilization since that is often the 
thing that cannot hit the confidence intervals, and leave the aggregate 
throughput as the proxy for efficiency change - which is why <burst> needs to 
take something to saturation in each case.

happy benchmarking,

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