netdev - Re: Accelerated receive flow steering (aRFS) for UDP

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:   Sun, 09 Oct 2016 15:33:22 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     "Chopra, Manish" <Manish.Chopra@...ium.com>,
        Rick Jones <rick.jones2@...com>
Cc:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "maorg@...lanox.com" <maorg@...lanox.com>,
        "tom@...bertland.com" <tom@...bertland.com>
Subject: Re: Accelerated receive flow steering (aRFS) for UDP

On Sun, 2016-10-09 at 19:48 +0000, Chopra, Manish wrote:

> Hi Eric, I used "-n" as well with "-N" but still the problem doesn't
> go away.
> 
> This is what I have done -
> 
> Started "netserver" on local/test setup
> 
> #netserver
> Starting netserver with host 'IN(6)ADDR_ANY' port '12865' and family
> AF_UNSPEC
> 
> It starts listening on port "12865"
> 
> From remote setup, started multiple netperf using different ports for
> data sockets specified using "-P" with "-N" and "-n" options specified
> as well.
> netperf -H 192.168.200.40 -l 150 -t UDP_STREAM -T 8,8 -- -N -n -m 1400
> -P 6660,5550 &
> netperf -H 192.168.200.40 -l 150 -t UDP_STREAM -T 9,9 -- -N -n -m 1400
> -P 9990,9880 &
> netperf -H 192.168.200.40 -l 150 -t UDP_STREAM -T 10,10 -- -N -n -m
> 1400 -P 4455,4400 &
> netperf -H 192.168.200.40 -l 150 -t UDP_STREAM -T 11,11 -- -N -n -m
> 1400 -P 3300,7800 &
> netperf -H 192.168.200.40 -l 150 -t UDP_STREAM -T 12,12 -- -N -n -m
> 1400 -P 50512,44444 &
> netperf -H 192.168.200.40 -l 150 -t UDP_STREAM -T 13,13 -- -N -n -m
> 1400 -P 10512,45672 &
> netperf -H 192.168.200.40 -l 150 -t UDP_STREAM -T 14,14 -- -N -n -m
> 1400 -P 8888,56721 &
> netperf -H 192.168.200.40 -l 150 -t UDP_STREAM -T 15,15 -- -N -n -m
> 1400 -P 9300,8899 &
> 
> When on local/test receiving setup, I dump skb's IP header protocol
> field in .ndo_rx_flow_steer() handler - it is still always
> IPPROTO_TCP.
> Which has destined port 12865. But that handler never receives a SKB
> whose IP header protocol field is set to IPPROTO_UDP.
> 
> As suspected, I believe in receive flow, packets always go in the path
> where it never match any entry in global flow table in get_rps_cpu()
> function
> ,possibly due to packets don't get received from the flow of
> inet_recvmsg() which updates the global flow table ?
> 
> 3571                 /* First check into global flow table if there is
> a match */
> 3572                 ident = sock_flow_table->ents[hash &
> sock_flow_table->mask];
> 3573                 if ((ident ^ hash) & ~rps_cpu_mask)
> 3574                         goto try_rps;
> 
> Hence, it never call set_rps_cpu() which internally is supposed to
> call .ndo_rx_flow_steer() for the SKB's whose flows to be steered.
> 
> On another side, when I use "Iperf" for sending UDP stream, which I
> believe receives the packets from the intet_recvmsg() flow
> and I do see flows getting steered for UDP packets. [Actually seeing
> SKB's whose IP header protocol set to IPPROTO_UDP arriving
> in .ndo-rx_flow_steer()].
> 
> iperf -s -u
> iperf -u -c 192.168.200.40 -t 3000 -i 10 -P 8


OK, I am adding/CC Rick Jones, netperf author, since it seems a netperf
bug, not a kernel one.

I believe I already mentioned fact that "UDP_STREAM -- -N" was not doing
a connect() on the receiver side.


> 
> 
>