From: Stephen Hemminger <stephen@networkplumber.org>
To: Bing Zhao <bingz@nvidia.com>
Cc: <viacheslavo@nvidia.com>, <dev@dpdk.org>, <rasland@nvidia.com>,
<orika@nvidia.com>, <dsosnowski@nvidia.com>,
<suanmingm@nvidia.com>, <matan@nvidia.com>, <thomas@monjalon.net>
Subject: Re: [PATCH v8] ethdev: support inline calculating masked item value
Date: Fri, 16 Oct 2026 09:03:20 -0700 [thread overview]
Message-ID: <20261016090320.31d42667@phoenix.local> (raw)
In-Reply-To: <20261016052645.288851-1-bingz@nvidia.com>
On Fri, 16 Oct 2026 08:26:45 +0300
Bing Zhao <bingz@nvidia.com> wrote:
> Drivers implementing synchronous flow rules through the asynchronous
> template API need to apply item masks before creating a rule. The spec
> and last pointers are const, so this requires writable copies and
> per-item knowledge of their sizes.
>
> Add RTE_FLOW_CONV_OP_PATTERN_MASKED to rte_flow_conv(). It copies the
> pattern like RTE_FLOW_CONV_OP_PATTERN and ANDs the inline fields of each
> copied spec and last with an explicit item mask. A NULL mask leaves the
> values unchanged; default masks are not substituted.
>
> Preserve GENEVE_OPT.option_len and TAG.index because they describe the
> pointed-to data length and select the tag register, respectively.
> RAW pattern and GENEVE_OPT data are copied without applying their
> payload masks. Limit this operation to inline fields, leaving
> variable-length payload masking to the caller. FLEX, COMPARE and PMD
> private items are not masked.
>
> Signed-off-by: Bing Zhao <bingz@nvidia.com>
> Reviewed-by: Dariusz Sosnowski <dsosnowski@nvidia.com>
> ---
Before merging:
1. Need this warning fixed.
2. Need a driver to support.
It doesn't make sense to have things in ethdev until a driver uses it. (YAGNI)
Make a patch series for mlx5 with this as the first patch.
[PATCH v8] ethdev: support inline calculating masked item value
v7 comments on GENEVE_OPT option_len, TAG index and the commit
message are addressed. Applies to main (26.11-rc1), builds with
-Dwerror=true.
Warning
1. INTEGRITY level is a selector and is still masked.
rte_flow_item_integrity.level picks the encapsulation level, same
class as TAG index. rte_flow_item_integrity_mask has level = 0, so a
rule passing the default mask explicitly gets level zeroed, turning
an inner integrity match into an outer one. mlx5 SWS reads the
unmasked spec->level (flow_dv_translate_item_integrity(),
"if (spec->level > 1)").
level is the first member, so an offsetof() end limit does not work.
Return a range instead:
static inline size_t
rte_flow_conv_item_mask_range(const struct rte_flow_item *item,
size_t *start)
{
*start = 0;
...
case RTE_FLOW_ITEM_TYPE_INTEGRITY:
*start = offsetof(struct rte_flow_item_integrity,
value);
return sizeof(struct rte_flow_item_integrity);
...
}
and in rte_flow_conv_pattern():
end = RTE_MIN(ret, item_mask_end);
if (c_spec && mask && end > start)
rte_flow_conv_apply_mask(c_spec + start, mask + start,
end - start);
Add INTEGRITY to the exception lists (rte_flow.h, helper comment,
release notes) and a test case.
2. Still no user of the new op.
Nothing in tree calls RTE_FLOW_CONV_OP_PATTERN_MASKED. Send it in a
series with the mlx5 change that uses it.
Info
3. NULL mask is not replaced by the default mask.
flow_offload.rst says spec without mask means the default mask. The
default masks are now in rte_flow_desc_item[].default_mask, so the
op could do it:
mask = src->mask;
if (mask == NULL && (int)src->type >= 0)
mask = rte_flow_desc_item[src->type].default_mask;
As written, every caller has to handle the NULL case itself. If
leaving it out is intended, say why in the commit message.
prev parent reply other threads:[~2026-10-16 16:03 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-17 7:54 [PATCH 1/2] lib/ethdev: support inline calculating masked item value Bing Zhao
2025-11-17 17:25 ` Stephen Hemminger
2026-02-05 8:45 ` Bing Zhao
2026-02-05 16:42 ` Stephen Hemminger
2026-02-09 4:23 ` Bing Zhao
2026-02-09 14:17 ` Bing Zhao
2026-02-09 18:58 ` Stephen Hemminger
2026-02-09 21:46 ` Thomas Monjalon
2026-02-13 13:31 ` [PATCH v2] " Bing Zhao
2026-02-13 19:50 ` Stephen Hemminger
2026-06-03 8:19 ` [PATCH v3] ethdev: " Bing Zhao
2026-06-03 9:28 ` [PATCH v4] " Bing Zhao
2026-06-08 14:49 ` Dariusz Sosnowski
2026-06-08 15:45 ` Stephen Hemminger
2026-06-09 5:23 ` Bing Zhao
2026-06-10 5:27 ` [PATCH v5] " Bing Zhao
2026-06-10 15:46 ` Stephen Hemminger
2026-06-11 4:55 ` Bing Zhao
2026-06-11 4:56 ` Bing Zhao
2026-10-07 16:57 ` [PATCH v6] " Bing Zhao
2026-10-08 7:17 ` Bing Zhao
2026-10-08 15:27 ` Stephen Hemminger
2026-10-13 13:49 ` [PATCH v7] " Bing Zhao
2026-10-13 15:45 ` Stephen Hemminger
2026-10-16 5:26 ` [PATCH v8] " Bing Zhao
2026-10-16 16:03 ` Stephen Hemminger [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261016090320.31d42667@phoenix.local \
--to=stephen@networkplumber.org \
--cc=bingz@nvidia.com \
--cc=dev@dpdk.org \
--cc=dsosnowski@nvidia.com \
--cc=matan@nvidia.com \
--cc=orika@nvidia.com \
--cc=rasland@nvidia.com \
--cc=suanmingm@nvidia.com \
--cc=thomas@monjalon.net \
--cc=viacheslavo@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox