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: <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

Powered by Openwall GNU/*/Linux Powered by OpenVZ