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

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

On 17/02/2026 23:57, Jakub Kicinski wrote:
> On Mon, 16 Feb 2026 10:28:52 +0200 Tariq Toukan wrote:
>>>> 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.
>>
>> There is a limitation, we read it from FW.
>> It's usually not small, much larger than 256.
>>
>> But currently it can vary according to FW decisions in scale (resource
>> management).
>>
>>> 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?
>>
>> It is possible, depending on the exposed FW capability.
>> As of today, there are high-scale configurations (many VFs for example)
>> where the FW exposed cap is lowered.
> 
> Not entirely sure what you expect the outcome of this discussion to be.
> 
> The 2x indirection table has been proven inadequate for real production
> use. I'm not talking about some theory or benchmarks, actual workloads
> reported machines/NICs with such table as unusable (workload starts
> choking way before reaching expected machine capacity).
> 
> That said I just checked out of curiosity and the OCP NIC spec also
> states:
> 
>    The minimum supported indirection table size MUST be 128.

That should be fine. Max table size cap is always >= 256.

> The minimum
>    SHOULD be at least 4 times the number of supported receive queues.
> 
> so I guess the 4x isn't exactly a new recommendation.

My position is as follows:
Provide the appropriate factor *if possible* (currently it is 2x, and we 
will likely increase it to 4x).
However, do not limit the maximum nch if the factor cannot be satisfied 
- even if that results in the selftest failing.