Re: [PATCH net-next] net: expand NETDEV_RSS_KEY_LEN to 256 bytes

[Jakub Kicinski <kuba@kernel.org>]

On Thu, 22 Jan 2026 16:16:43 -0500 Willem de Bruijn wrote:
> > > Iff respinning it may be informative to explain how drivers intend to
> > > use limits beyond standard Toeplitz. The tunneling that Jakub
> > > mentioned. AFAIK there is no Linux control API to configure the device
> > > RSS block in that way?  
> > 
> > How the NIC does header analysis and RSS computation is up to the NIC vendor.
> > 
> > They provide some knobs, but not a way of using user-defined RSS
> > hashing for some particular encapsulations.
> > 
> > Some NIC use a TCAM, and they do not use the RSS keys in sequence.
> > Say if one 4byte member of the L4 4-tuple starts at offset 130, the
> > NIC will use rss_key[130-xx] :rss_key[133-xx]  
> 
> I see. That is no longer RSS as defined. But that's moot. The point of
> the sysfs interface is to be able to share keys across netdevices for
> consistent behavior. For whatever algorithm it uses.

Perhaps stating the obvious - the first ~52B of the key still have
the well defined semantics. So for normal traffic / non-esoteric field
configuration user can still use the standard calculation. Unless we
bump the limit, however, those NICs can't use netdev_rss_key_fill().
Well, they could copy in just the 52B and then append some extra
entropy after but nobody bothers...