[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANn89iKtX7Omh7qXwt7A1=Q3nQ4VgVOAzWfgNBO-t0xWP7RKpQ@mail.gmail.com>
Date: Thu, 22 Jan 2026 21:40:43 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: "David S . Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>,
Willem de Bruijn <willemb@...gle.com>, netdev@...r.kernel.org, eric.dumazet@...il.com
Subject: Re: [PATCH net-next] net: expand NETDEV_RSS_KEY_LEN to 256 bytes
On Thu, Jan 22, 2026 at 9:22 PM Willem de Bruijn
<willemdebruijn.kernel@...il.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]
>
> >
> > 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@...nel.org>
> > Link: https://lore.kernel.org/netdev/20260122075206.504ec591@kernel.org/
> > Signed-off-by: Eric Dumazet <edumazet@...gle.com>
>
> Reviewed-by: Willem de Bruijn <willemb@...gle.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.
Powered by blists - more mailing lists