Hi David, 🤖 This review was drafted with assistance from Claude (Anthropic) and reviewed by me before posting.
This is the patch that raises the effective unicast MAC limit (priv->sh->dev_cap.max_mac_addrs, up to ~4096 per the FW capability), but it misses two consumers in the HWS control-flow path that still use the old fixed constants: 1. __flow_hw_ctrl_flows_unicast() / __flow_hw_ctrl_flows_unicast_vlan() (drivers/net/mlx5/mlx5_flow_hw.c, ~line 16703 and ~16770) still loop over indices 0..MLX5_MAX_MAC_ADDRESSES-1 (256) instead of priv->sh->dev_cap.max_mac_addrs. On a device that now reports a larger capability, a unicast MAC added at index >= 256 via rte_eth_dev_mac_addr_add() succeeds at the mlx5_mac_addr_add() level, but no HWS control-flow rule gets created for it -- traffic to that MAC is silently not steered. The non-HWS path in mlx5_trigger.c was updated in this same patch, so this looks like an oversight. This one is the more important of the two to fix. 2. ctrl_rx_nb_flows_map[MLX5_FLOW_HW_CTRL_RX_ETH_PATTERN_DMAC] (mlx5_flow_hw.c, ~line 11588) still sizes the DMAC control-flow template table with the old fixed MLX5_MAX_UC_MAC_ADDRESSES (128). With more than 128 unicast MACs configured on a capable device, flow_hw_create_ctrl_flow() for the 129th+ MAC would fail even though mlx5_mac_addr_add() reported success. Could you address these in a v2? -- Raslan Darawsheh
