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. 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? 256 is not a lot, AMD Venice (to pick one) will have up to 256 CPU cores (not threads) in a single CPU package.
