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

[Jakub Kicinski <kuba@kernel.org>]

On Thu, 12 Feb 2026 11:41:19 +0200 Tariq Toukan wrote:
> On 11/02/2026 23:43, Jakub Kicinski wrote:
> > 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.
> 
> No doubt that larger factors help overcome imbalance issues, and it's 
> fine to recommend using 4x (or even larger) factors.
> 
> The point is, when this comes with a selftest, it's less of a 
> recommendation/guidance anymore, it becomes kind of a requirement, an 
> expected behavior. Otherwise the test fails.
> 
> This ignores multiple other considerations:
> 
> 1. Existing behavior: In general, mlx5e today implies 2x factor, so it 
> would fail this new test.
> 
> 2. Device resources: In large scale (high num of channels, or high num 
> of netdevs on the same chip, or both), it is not obvious that increasing 
> the indirection table size is still desirable, or even possible. To pass 
> the selftest, you'll have to limit the max number of channels.
> 
> 3. ch_max should win: Related to point #2. Driver should not enforce 
> limitations on supported ch_max just to fulfill the recommendation and 
> pass the test. I prefer flexibility, give the admin the control. That 
> means, driver would use 4x factor (or larger) whenever possible, but 
> would not block configurations in which the 4x factor cannot be satisfied.

Oh I see.. I wasn't aware the CX7 has a limitation of the indirection
table size. I wrote the test because of a similar limitation in a
different NIC, but that one has been fixed.. I have limited access to
CX7 NICs, the one I tested on maxed out at 63 queues so the test has
passed.

Is it not possible to create an indirection table larger than 256
entries? 256 is not a lot, AMD Venice (to pick one) will have up 
to 256 CPU cores (not threads) in a single CPU package.