[PATCH v5] net/mlx5: prepend implicit items in sync flow creation path
Raslan Darawsheh
rasland at nvidia.com
Thu Jun 4 11:37:32 CEST 2026
Hi,
On 27/05/2026 1:35 PM, Maxime Peim wrote:
> In eSwitch mode, the async (template) flow creation path automatically
> prepends implicit match items to scope flow rules to the correct
> representor port:
> - Ingress: REPRESENTED_PORT item matching dev->data->port_id
> - Egress: REG_C_0 TAG item matching the port's tx tag value
>
> The sync path (flow_hw_list_create) was missing this logic, causing all
> flow rules created via the non-template API to match traffic from all
> ports rather than being scoped to the specific representor.
>
> Add the same implicit item prepending to flow_hw_list_create, right
> after pattern validation and before any branching (sample/RSS/single/
> prefix), mirroring the behavior of flow_hw_pattern_template_create
> and flow_hw_get_rule_items. The ingress case prepends
> REPRESENTED_PORT with the current port_id; the egress case prepends
> MLX5_RTE_FLOW_ITEM_TYPE_TAG with REG_C_0 value/mask (skipped when
> user provides an explicit SQ item).
>
> Also fix a pre-existing bug where 'return split' on metadata split
> failure returned a negative int cast to uintptr_t, which callers
> would treat as a valid flow handle instead of an error.
>
> Fixes: e38776c36c8a ("net/mlx5: introduce HWS for non-template flow API")
> Fixes: 821a6a5cc495 ("net/mlx5: add metadata split for compatibility")
> Signed-off-by: Maxime Peim <maxime.peim at gmail.com>
> ---
> v3:
> - Factor the implicit-item prepend logic out of
> flow_hw_pattern_template_create() into a new helper
> flow_hw_adjust_pattern() and reuse it from flow_hw_list_create(),
> instead of duplicating the prepend logic inline in the sync path.
> - Zero-initialize item_flags in both callers. The validator is
> read-modify-write on item_flags (reads MLX5_FLOW_LAYER_TUNNEL on
> the first iteration), so leaving it uninitialized was UB.
> - Call __flow_hw_pattern_validate() with nt_flow=true from the sync
> path (was effectively nt_flow=false via the wrapper), restoring the
> previous behavior that skips GENEVE_OPT TLV parser validation on
> the non-template path.
> - Document flow_hw_adjust_pattern(): the dual role of the nt_flow
> parameter (template spec-left-zero vs. sync spec-filled + validator
> flag), the three-way return, and the caller's ownership of
> *copied_items across every exit path.
> - Clarify the "omitting implicit REG_C_0 match" debug log now that
> the helper runs on both the template and sync paths.
> - Add Fixes: tags for the two original commits.
>
> v4:
> - Fix items in case splitted metadata are not needed.
>
> v5:
> - Make flow_hw_prepend_item() return a self-contained array. The
> helper used to shallow-copy the prepended item, leaving its
> .spec/.mask pointing at flow_hw_adjust_pattern()'s stack locals
> (port_spec, tag_v, tag_m); once that frame returned, the
> consumers in flow_hw_list_create() (sample / RSS / single create)
> and the post-extraction template path dereferenced dangling
> pointers. The prepended item is now deep-copied via
> rte_flow_conv(RTE_FLOW_CONV_OP_ITEM, ...) into the tail of the
> same mlx5_malloc() block, so the lifetime of every byte the
> consumer can reach equals the lifetime of the returned array.
> items[] continue to be shallow-copied (their spec/mask blobs are
> application-owned and outlive the call). One alloc, one free; no
> call-site or signature changes.
> - Fix the &item_flags / &orig_item_nb argument order at both
> flow_hw_adjust_pattern() call sites (introduced in v3 by the
> helper extraction): the prior order silently stored the item
> count into it->item_flags / the layer-flag arguments forwarded
> into mlx5_nta_sample_flow_list_create / mlx5_flow_nta_handle_rss /
> mlx5_flow_hw_create_flow, and stored the OR-accumulated layer
> flags into it->orig_item_nb / per-rule item-count uses.
>
> drivers/net/mlx5/mlx5_flow_hw.c | 262 +++++++++++++++++++++++---------
> 1 file changed, 194 insertions(+), 68 deletions(-)
>
--
Patch applied to next-net-mlx,
Kindest regards
Raslan Darawsheh
More information about the dev
mailing list