On Thu, 18 Sep 2025 18:16:14 +0300 Carolina Jubran wrote: > On 18/09/2025 17:35, Jakub Kicinski wrote: > > On Thu, 18 Sep 2025 17:25:40 +0300 Carolina Jubran wrote: > >>> why does MLX5E_FEC_RS_HIST_MAX exist? > >>> We care that bins_cnt <= ETHTOOL_FEC_HIST_MAX - 1 > >>> or is there something in the interface that hardcodes 16? > >> My intention was to keep mlx5 capped at 16 even if ethtool raises its max. > >> We’ll only increase this once we know the device should expose more than > >> 16. > >> Since our HW has internal modes that can report more than 16 bins, this > >> ensures we don’t accidentally expose them if ethtool increases its max. > > But why? > > Because currently those modes shouldn't be exposed for ethernet.
I understand that the modes should not be exposed. I don't get why this has anything to do with the number of bins. Does the FW hardcode that the non-Ethernet modes use bins >=16? When you say "internal modes that can report more than 16 bins" it sounds like it uses bins starting from 0, e.g. 0..31.
