netdev - Re: Netperf UDP issue with connected sockets

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, 30 Nov 2016 09:42:40 -0800
From:   Rick Jones <rick.jones2@....com>
To:     Jesper Dangaard Brouer <brouer@...hat.com>
Cc:     Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org
Subject: Re: Netperf UDP issue with connected sockets

On 11/30/2016 02:43 AM, Jesper Dangaard Brouer wrote:
> Notice the "fib_lookup" cost is still present, even when I use
> option "-- -n -N" to create a connected socket.  As Eric taught us,
> this is because we should use syscalls "send" or "write" on a connected
> socket.

In theory, once the data socket is connected, the send_data() call in 
src/nettest_omni.c is supposed to use send() rather than sendto().

And indeed, based on a quick check, send() is what is being called, 
though it becomes it seems a sendto() system call - with the destination 
information NJULL:

write(1, "send\n", 5)                   = 5
sendto(4, "netperf\0netperf\0netperf\0netperf\0"..., 1024, 0, NULL, 0) = 
1024
write(1, "send\n", 5)                   = 5
sendto(4, "netperf\0netperf\0netperf\0netperf\0"..., 1024, 0, NULL, 0) = 
1024

So I'm not sure what might be going-on there.

You can get netperf to use write() instead of send() by adding a 
test-specific -I option.

happy benchmarking,

rick

>
> My udp_flood tool[1] cycle through the different syscalls:
>
> taskset -c 2 ~/git/network-testing/src/udp_flood 198.18.50.1 --count $((10**7)) --pmtu 2
>              	ns/pkt	pps		cycles/pkt
> send      	473.08	2113816.28	1891
> sendto    	558.58	1790265.84	2233
> sendmsg   	587.24	1702873.80	2348
> sendMmsg/32  	547.57	1826265.90	2189
> write     	518.36	1929175.52	2072
>
> Using "send" seems to be the fastest option.
>
> Some notes on test: I've forced TX completions to happen on another CPU0
> and pinned the udp_flood program (to CPU2) as I want to avoid the CPU
> scheduler to move udp_flood around as this cause fluctuations in the
> results (as it stress the memory allocations more).
>
> My udp_flood --pmtu option is documented in the --help usage text (see below signature)
>