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

On 11/16/2016 02:40 PM, Jesper Dangaard Brouer wrote:
> On Wed, 16 Nov 2016 09:46:37 -0800
> Rick Jones <rick.jones2@....com> wrote:
>> It is a wild guess, but does setting SO_DONTROUTE affect whether or not
>> a connect() would have the desired effect?  That is there to protect
>> people from themselves (long story about people using UDP_STREAM to
>> stress improperly air-gapped systems during link up/down testing....)
>> It can be disabled with a test-specific -R 1 option, so your netperf
>> command would become:
>>
>> netperf -H 198.18.50.1 -t UDP_STREAM -l 120 -- -m 1472 -n -N -R 1
>
> Using -R 1 does not seem to help remove __ip_select_ident()

Bummer.  It was a wild guess anyway, since I was seeing a connect() call 
on the data socket.

> Samples: 56K of event 'cycles', Event count (approx.): 78628132661
>   Overhead  Command        Shared Object        Symbol
> +    9.11%  netperf        [kernel.vmlinux]     [k] __ip_select_ident
> +    6.98%  netperf        [kernel.vmlinux]     [k] _raw_spin_lock
> +    6.21%  swapper        [mlx5_core]          [k] mlx5e_poll_tx_cq
> +    5.03%  netperf        [kernel.vmlinux]     [k] copy_user_enhanced_fast_string
> +    4.69%  netperf        [kernel.vmlinux]     [k] __ip_make_skb
> +    4.63%  netperf        [kernel.vmlinux]     [k] skb_set_owner_w
> +    4.15%  swapper        [kernel.vmlinux]     [k] __slab_free
> +    3.80%  netperf        [mlx5_core]          [k] mlx5e_sq_xmit
> +    2.00%  swapper        [kernel.vmlinux]     [k] sock_wfree
> +    1.94%  netperf        netperf              [.] send_data
> +    1.92%  netperf        netperf              [.] send_omni_inner

Well, the next step I suppose is to have you try a quick netperf 
UDP_STREAM under strace to see if your netperf binary does what mine did:

strace -v -o /tmp/netperf.strace netperf -H 198.18.50.1 -t UDP_STREAM -l 
1 -- -m 1472 -n -N -R 1

And see if you see the connect() I saw. (Note, I make the runtime 1 second)

rick