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.
