Re: [PATCH mlx5-next 8/8] {net/RDMA}/mlx5: Add LAG demux table API and vport demux rules

[Mark Bloch]

On 08/03/2026 17:52, Jakub Kicinski wrote:
> On Sun, 8 Mar 2026 08:55:59 +0200 Tariq Toukan wrote:
>> +struct mlx5_flow_handle *
>> +mlx5_esw_lag_demux_rule_create(struct mlx5_eswitch *esw, u16 vport_num,
>> +			       struct mlx5_flow_table *lag_ft)
>> +{
>> +	struct mlx5_flow_spec *spec = kvzalloc(sizeof(*spec), GFP_KERNEL);
>> +	struct mlx5_flow_destination dest = {};
>> +	struct mlx5_flow_act flow_act = {};
>> +	struct mlx5_flow_handle *ret;
>> +	void *misc;
>> +
>> +	if (!spec)
>> +		return ERR_PTR(-ENOMEM);
>> +
>> +	if (!mlx5_eswitch_vport_match_metadata_enabled(esw)) {
>> +		kfree(spec);
>> +		return ERR_PTR(-EOPNOTSUPP);
>> +	}
>> +
>> +	misc = MLX5_ADDR_OF(fte_match_param, spec->match_criteria,
>> +			    misc_parameters_2);
>> +	MLX5_SET(fte_match_set_misc2, misc, metadata_reg_c_0,
>> +		 mlx5_eswitch_get_vport_metadata_mask());
>> +	spec->match_criteria_enable = MLX5_MATCH_MISC_PARAMETERS_2;
>> +
>> +	misc = MLX5_ADDR_OF(fte_match_param, spec->match_value,
>> +			    misc_parameters_2);
>> +	MLX5_SET(fte_match_set_misc2, misc, metadata_reg_c_0,
>> +		 mlx5_eswitch_get_vport_metadata_for_match(esw, vport_num));
>> +
>> +	flow_act.action = MLX5_FLOW_CONTEXT_ACTION_FWD_DEST;
>> +	dest.type = MLX5_FLOW_DESTINATION_TYPE_VHCA_RX;
>> +	dest.vhca.id = MLX5_CAP_GEN(esw->dev, vhca_id);
>> +
>> +	ret = mlx5_add_flow_rules(lag_ft, spec, &flow_act, &dest, 1);
>> +	kfree(spec);
>> +	return ret;
>> +}
> 
> drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c:1512:12-13: WARNING kvmalloc is used to allocate this memory at line 1502
> drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c:1532:11-12: WARNING kvmalloc is used to allocate this memory at line 1502
Hi Jakub,

Thanks for catching this. We’ll address it.

Also, I saw IA flagged issues con
“net/mlx5: LAG, replace pf array with xarray”.
Just for context, lag_lock is already a known problematic
area for us, and we do have plans to remove it. I ran the
review prompts locally in ORC mode, so I assume I saw the
same comments as NIPA.

So the issue raised there is not really a new one. lag_lock
already has some known issues today, but we do not expect to
hit this particular case in practice, since by the time
execution reaches mdev removal, the LAG should already have
been destroyed and the netdevs already removed for the driver
internal structures.

Mark