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.
