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

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

On 13/02/2026 3:22, Jakub Kicinski wrote:
> 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.

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.

> 256 is not a lot, AMD Venice (to pick one) will have up
> to 256 CPU cores (not threads) in a single CPU package.