Thread (139 messages) flat view 139 messages, 9 authors, 1d ago

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

From: Raslan Darawsheh <hidden>
Date: 2026-09-23 11:56:13

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help