When creating vport actions for hotplugged SF/VF representors in flow_hw_create_vport_action(), the function incorrectly used is_unified_fdb(priv) where priv is the representor's private data.
However, the vport action is stored in proxy_priv->hw_vport[] and will be used by flows on the proxy port. Since representors have unified_fdb_en=false while the proxy port (PF) may have it enabled, this caused a flag mismatch: - Proxy port (port 0): unified FDB enabled - SF representors (ports 2, 3): unified FDB disabled - Vport actions for SFs created with MLX5DR_ACTION_FLAG_HWS_FDB - But flows on proxy port use unified FDB mode This resulted in REPRESENTED_PORT actions counting packets correctly (flow matches work) but not actually forwarding them to the destination vport. Fix by using is_unified_fdb(proxy_priv) to ensure the vport action flags match the proxy port's FDB mode, which is where the action will actually be used. Fixes: flow_hw_create_vport_action() vport flag selection Signed-off-by: Max Tottenham <[email protected]> --- drivers/net/mlx5/mlx5_flow_hw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/mlx5/mlx5_flow_hw.c b/drivers/net/mlx5/mlx5_flow_hw.c index c41b99746f..a9d342579b 100644 --- a/drivers/net/mlx5/mlx5_flow_hw.c +++ b/drivers/net/mlx5/mlx5_flow_hw.c @@ -9528,7 +9528,7 @@ flow_hw_create_vport_action(struct rte_eth_dev *dev) } proxy_priv->hw_vport[port_id] = mlx5dr_action_create_dest_vport (proxy_priv->dr_ctx, priv->dev_port, - is_unified_fdb(priv) ? + is_unified_fdb(proxy_priv) ? (MLX5DR_ACTION_FLAG_HWS_FDB_RX | MLX5DR_ACTION_FLAG_HWS_FDB_TX | MLX5DR_ACTION_FLAG_HWS_FDB_UNIFIED) : -- 2.52.0
