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

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

[Eric Dumazet]

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.

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>
---
 Documentation/admin-guide/sysctl/net.rst | 13 +++++++------
 include/linux/netdevice.h                |  3 +--
 net/core/sysctl_net_core.c               | 10 ++++++++--
 3 files changed, 16 insertions(+), 10 deletions(-)

diff --git a/Documentation/admin-guide/sysctl/net.rst b/Documentation/admin-guide/sysctl/net.rst
index 91fa4ccd326c2b6351fd028a1c5d1c69126bee5f..19408da2390b013b06ca92b16c152d48a5efbc1e 100644
--- a/Documentation/admin-guide/sysctl/net.rst
+++ b/Documentation/admin-guide/sysctl/net.rst
@@ -314,21 +314,22 @@ Default: 1000
 netdev_rss_key
 --------------
 
-RSS (Receive Side Scaling) enabled drivers use a 40 bytes host key that is
-randomly generated.
+RSS (Receive Side Scaling) enabled drivers use a host key that
+is randomly generated.
 Some user space might need to gather its content even if drivers do not
 provide ethtool -x support yet.
 
 ::
 
   myhost:~# cat /proc/sys/net/core/netdev_rss_key
-  84:50:f4:00:a8:15:d1:a7:e9:7f:1d:60:35:c7:47:25:42:97:74:ca:56:bb:b6:a1:d8: ... (52 bytes total)
+  84:50:f4:00:a8:15:d1:a7:e9:7f:1d:60:35:c7:47:25:42:97:74:ca:56:bb:b6:a1:d8: ... (256 bytes total)
 
-File contains nul bytes if no driver ever called netdev_rss_key_fill() function.
+File contains all nul bytes if no driver ever called netdev_rss_key_fill()
+function.
 
 Note:
-  /proc/sys/net/core/netdev_rss_key contains 52 bytes of key,
-  but most drivers only use 40 bytes of it.
+  /proc/sys/net/core/netdev_rss_key contains 256 bytes of key,
+  but many drivers only use 40 or 52 bytes of it.
 
 ::
 
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index d99b0fbc1942ad1dbbd372cfb9e809e413251f15..3524c54c786a94a1e797c07d6b2d1cf35b6cbc5b 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -5163,8 +5163,7 @@ void *netdev_lower_dev_get_private(struct net_device *dev,
 void netdev_lower_state_changed(struct net_device *lower_dev,
 				void *lower_state_info);
 
-/* RSS keys are 40 or 52 bytes long */
-#define NETDEV_RSS_KEY_LEN 52
+#define NETDEV_RSS_KEY_LEN 256
 extern u8 netdev_rss_key[NETDEV_RSS_KEY_LEN] __read_mostly;
 void netdev_rss_key_fill(void *buffer, size_t len);
 
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);
 	fake_table.data = buf;
 	fake_table.maxlen = sizeof(buf);
 	return proc_dostring(&fake_table, write, buffer, lenp, ppos);
-- 
2.52.0.457.g6b5491de43-goog

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

[Willem de Bruijn]

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?

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

>  	fake_table.data = buf;
>  	fake_table.maxlen = sizeof(buf);
>  	return proc_dostring(&fake_table, write, buffer, lenp, ppos);
> -- 
> 2.52.0.457.g6b5491de43-goog
> 

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

[Eric Dumazet]

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]

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

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

[Willem de Bruijn]

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.

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

[Jakub Kicinski]

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

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

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Thu, 22 Jan 2026 19:03:49 +0000 you 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.
> 
> Since this change might cause some issues in admin scripts,
> bump it directly to 256 in one go.
> 
> [...]

Here is the summary with links:
  - [net-next] net: expand NETDEV_RSS_KEY_LEN to 256 bytes
    https://git.kernel.org/netdev/net-next/c/37b0ea8fef56

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html