netdev - Re: [PATCH net-next v2 1/2] selftests: drv-net: rss: validate min RSS table size

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] [day] [month] [year] [list]

Message-ID: <20260211134319.39710c1d@kernel.org>
Date: Wed, 11 Feb 2026 13:43:19 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Yael Chemla <ychemla@...dia.com>
Cc: davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com,
 pabeni@...hat.com, andrew+netdev@...n.ch, horms@...nel.org, Willem de
 Bruijn <willemb@...gle.com>, shuah@...nel.org,
 linux-kselftest@...r.kernel.org, Tariq Toukan <tariqt@...dia.com>, Gal
 Pressman <gal@...dia.com>, noren@...dia.com
Subject: Re: [PATCH net-next v2 1/2] selftests: drv-net: rss: validate min
 RSS table size

On Wed, 11 Feb 2026 22:10:56 +0200 Yael Chemla wrote:
> Thanks for the test addition. I wanted to raise a concern regarding the
> spread factor requirement that may apply to mlx5 and potentially other
> drivers as well.
> The real issue arises when the hardware's maximum RQT (indirection
> table) size isn't large enough to accommodate both the desired number of
> channels and a spread factor of 4. RX queues/channels serve multiple
> purposes beyond RSS - they're also used for XDP, AF_XDP, and direct
> queue steering via ntuple filters or TC.
> Artificially limiting the number of channels based solely on RSS spread
> requirements would be overly restrictive for these non-RSS use cases.
> In such scenarios, we'd rather have a slightly degraded spread factor
> (< 4) than limit channel availability.
> We'd appreciate any feedback on this approach.

That's fine. In fact IIRC ixgbe (infamously) had more queues than 
it could fit in its RSS table. So none of this is new. At the same
time if user _does_ want to use a lot of queues in the main context
fewer than 4x entries in the indir table is inadequate.

The test is based on production experience, and provides valuable
guidance to device developers.

I'm not sure what you want me to say here.