Re: [PATCH v7 5/5] net/mlx5: accept more unicast MAC addresses

[Raslan Darawsheh <rasland@nvidia.com>]

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