Hi David, 🤖 This review was drafted with assistance from Claude (Anthropic) and reviewed by me before posting.
Thanks for fixing __flow_hw_ctrl_flows_unicast() / _vlan() to loop over priv->sh->dev_cap.max_mac_addrs. One more spot to check: ctrl_rx_nb_flows_map[MLX5_FLOW_HW_CTRL_RX_ETH_PATTERN_DMAC] (mlx5_flow_hw.c, ~line 11588) is a static initializer still set to the fixed MLX5_MAX_UC_MAC_ADDRESSES (128, unchanged by this series). That value becomes nb_flows -> cfg.max_idx (mlx5_flow_hw.c, ~line 5335), which hard-caps the ipool backing the DMAC/DMAC_VLAN control-flow template table, and this table isn't on the resizable-table path. So __flow_hw_ctrl_flows_unicast() now loops up to priv->sh->dev_cap.max_mac_addrs (which can be up to ~4096 per this series) and tries to insert one control-flow rule per configured unicast MAC into that same 128-capacity table. On any device that now advertises more than 128 unicast MACs -- which is the whole point of this series -- configuring more than 128 will make flow-rule insertion fail for the 129th+ MAC, even though mlx5_mac_addr_add() itself succeeded. Rx breaks silently for those addresses. Could you take a look at this one too? Thanks, Raslan
