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

[Jakub Kicinski <kuba@kernel.org>]

On Tue, 23 May 2023 12:49:06 +0200 Paolo Abeni wrote:
> > Previously, since the introduction of the driver, RSS hashing
> > was only performed on the source and destination IP addresses
> > of UDP packets thereby limiting UDP traffic to a single queue
> > for multiple connections on the same IP address. The transport
> > layer is now included in RSS hashing for UDP traffic, which
> > was not previously the case. The reason behind the previous
> > limitation is unclear - either a historic limitation of the
> > NFP device, or an oversight.  
> 
> FTR including the transport header in RSS hash for UDP will damage
> fragmented traffic, but whoever is relaying on fragments nowadays
> should have already at least a dedicated setup.

Yup, that's the exact reason it was disabled by default, FWIW.

The Microsoft spec is not crystal clear on how to handles this:
https://learn.microsoft.com/en-us/windows-hardware/drivers/network/rss-hashing-types#ndis_hash_ipv4
There is a note saying:

  If a NIC receives a packet that has both IP and TCP headers,
  NDIS_HASH_TCP_IPV4 should not always be used. In the case of a
  fragmented IP packet, NDIS_HASH_IPV4 must be used. This includes
  the first fragment which contains both IP and TCP headers.

While NDIS_HASH_UDP_IPV4 makes no such distinction and talks only about
"presence" of the header.

Maybe we should document that device is expected not to use the UDP
header if MF is set?