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

[Tariq Toukan <ttoukan.linux@gmail.com>]

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.