netdev - Re: [PATCH net-next] nfp: add L4 RSS hashing on UDP traffic

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]

Message-ID: <2ecb3189855ceb4f7399271bf99af5a27926e59c.camel@redhat.com>
Date: Wed, 24 May 2023 18:14:55 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Jakub Kicinski <kuba@...nel.org>, Willem de Bruijn
	 <willemdebruijn.kernel@...il.com>
Cc: Simon Horman <simon.horman@...igine.com>, Louis Peens
	 <louis.peens@...igine.com>, David Miller <davem@...emloft.net>, 
	netdev@...r.kernel.org, oss-drivers@...igine.com, Willem de Bruijn
	 <willemb@...gle.com>
Subject: Re: [PATCH net-next] nfp: add L4 RSS hashing on UDP traffic

On Wed, 2023-05-24 at 08:38 -0700, Jakub Kicinski wrote:
> On Wed, 24 May 2023 11:33:15 -0400 Willem de Bruijn wrote:
> > The OCP draft spec already has this wording, which covers UDP:
> > 
> > "RSS defines two rules to derive queue selection input in a
> > flow-affine manner from packet headers. Selected fields of the headers
> > are extracted and concatenated into a byte array. If the packet is
> > IPv4 or IPv6, not fragmented, and followed by a transport layer
> > protocol with ports, such as TCP and UDP, then extract the
> > concatenated 4-field byte array { source address, destination address,
> > source port, destination port }. Else, if the packet is IPv4 or IPv6,
> > extract 2-field byte array { source address, destination address }.
> > IPv4 packets are considered fragmented if the more fragments bit is
> > set or the fragment offset field is non-zero."
> 
> Ugh, that's what I thought. I swear I searched it for "fragment"
> yesterday and the search came up empty. I blame google docs :|
> 
> We should probably still document the recommendation that if the NIC
> does not comply and hashes on ports with MF set - it should disable 
> UDP hashing by default (in kernel docs).

FTR, the above schema could still move the same flow on different
queues - if some datagrams in the given flow are fragmented and some
are not.

Out of sheer ignorance I really don't know if/how many NICs implement
RSS hashing with the above schema (using different data according to
the IP header fragments related fields). I'm guessing some (most?) use
a simpler schema (always L4 if available or never L4).

I *think* we could as well suggest always using L4 for UDP. If users
care about fragments they will have to explicitly deal with them
anyway.

Cheers,

Paolo