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

[Willem de Bruijn <willemdebruijn.kernel@gmail.com>]

Eric Dumazet wrote:
> On Thu, Jan 22, 2026 at 9:22 PM Willem de Bruijn
> <willemdebruijn.kernel@gmail.com> wrote:
> >
> > Eric Dumazet wrote:
> > > NETDEV_RSS_KEY_LEN has been set to 52 bytes in 2014, until now.
> > >
> > > Jakub suggested we bump the size to 128 bytes or more.
> > >
> > > Some drivers (like idpf) were already working around the core limit.
> >
> > Idpf still bounds to the max?
> >
> > 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.
 
> >
> > >
> > > Since this change might cause some issues in admin scripts,
> > > bump it directly to 256 in one go.
> > >
> > > tjbp26:~# cat /proc/sys/net/core/netdev_rss_key | wc -c
> > > 768
> > >
> > > tjbp26:~# ethtool -x eth1
> > > RX flow hash indirection table for eth1 with 32 RX ring(s):
> > > ...
> > > RSS hash key:
> > > fe:16:5b:2f:93:85:c2:c9:c1:ef:bd:60:c6:e0:2b:99:4d:bf:b7:14:c8:1e:8d:cb:31:17:51:da:55:eb:91:d9:9e:f9:89:9b:44:a1:dc:08:72:3a:b3:d6:31:86:9a:fe:02:3a:0d:eb:a1:7c:f5:a3:51:3b:08:56:c9:3f:71:69:01:ba:70:38
> > > RSS hash function:
> > >     toeplitz: on
> > >     xor: off
> > >     crc32: off
> > >
> > > Suggested-by: Jakub Kicinski <kuba@kernel.org>
> > > Link: https://lore.kernel.org/netdev/20260122075206.504ec591@kernel.org/
> > > Signed-off-by: Eric Dumazet <edumazet@google.com>
> >
> > Reviewed-by: Willem de Bruijn <willemb@google.com>
> >
> > > diff --git a/net/core/sysctl_net_core.c b/net/core/sysctl_net_core.c
> > > index 05dd55cf8b58e6c6fce498a11c09f23fd56d8f34..0f761d4b94471a5f8bbe0810922cf59e009be99d 100644
> > > --- a/net/core/sysctl_net_core.c
> > > +++ b/net/core/sysctl_net_core.c
> > > @@ -325,10 +325,16 @@ static int proc_do_dev_weight(const struct ctl_table *table, int write,
> > >  static int proc_do_rss_key(const struct ctl_table *table, int write,
> > >                          void *buffer, size_t *lenp, loff_t *ppos)
> > >  {
> > > -     struct ctl_table fake_table;
> > >       char buf[NETDEV_RSS_KEY_LEN * 3];
> > > +     struct ctl_table fake_table;
> > > +     char *pos = buf;
> > > +
> > > +     for (int i = 0; i < NETDEV_RSS_KEY_LEN; i++) {
> > > +             pos = hex_byte_pack(pos, netdev_rss_key[i]);
> > > +             *pos++ = ':';
> > > +     }
> > > +     *(--pos) = 0;
> > >
> > > -     snprintf(buf, sizeof(buf), "%*phC", NETDEV_RSS_KEY_LEN, netdev_rss_key);
> >
> > Why change the print method?
> >
> 
> Because the existing one is limited to 64 bytes.
> 
> lib/vsprintf.c
> 
>  * - 'h[CDN]' For a variable-length buffer, it prints it as a hex string with
>  *            a certain separator (' ' by default):
>  *              C colon
>  *              D dash
>  *              N no separator
>  *            The maximum supported length is 64 bytes of the input. Consider
>  *            to use print_hex_dump() for the larger input.

I see. Thanks.