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. 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.
