[PATCH 1/2] lib/ethdev: support inline calculating masked item value

[Bing Zhao]

Sure. I will add some tests.

> -----Original Message-----
> From: Stephen Hemminger <stephen at networkplumber.org>
> Sent: Friday, February 6, 2026 12:43 AM
> To: Bing Zhao <bingz at nvidia.com>
> Cc: Slava Ovsiienko <viacheslavo at nvidia.com>; dev at dpdk.org; Raslan
> Darawsheh <rasland at nvidia.com>; Ori Kam <orika at nvidia.com>; Dariusz
> Sosnowski <dsosnowski at nvidia.com>; Suanming Mou <suanmingm at nvidia.com>;
> Matan Azrad <matan at nvidia.com>; NBU-Contact-Thomas Monjalon (EXTERNAL)
> <thomas at monjalon.net>
> Subject: Re: [PATCH 1/2] lib/ethdev: support inline calculating masked
> item value
> 
> External email: Use caution opening links or attachments
> 
> 
> On Mon, 17 Nov 2025 09:54:07 +0200
> Bing Zhao <bingz at nvidia.com> wrote:
> 
> > In the asynchronous API definition and some drivers, the rte_flow_item
> > spec value may not be calculated by the driver due to the reason of
> > speed of light rule insertion rate and sometimes the input parameters
> > will be copied and changed internally.
> >
> > After copying, the spec and last will be protected by the keyword
> > const and cannot be changed in the code itself. And also the driver
> > needs some extra memory to do the calculation and extra conditions to
> > understand the length of each item spec. This is not efficient.
> >
> > To solve the issue and support usage of the following fix, a new OP
> > was introduced to calculate the spec and last values after applying
> > the mask inline.
> >
> > Signed-off-by: Bing Zhao <bingz at nvidia.com>
> > ---
> 
> Looked at this patch again:
>   1. No API/ABI breakage adding a single flow type is going
>      to work great. rte_flow_conv_pattern is internal so changing is no
> problem.
>   2. No need for release note for single flow change.
> 
>   3. Do need a test to cover the new code. I know rte_flow is way under
> tested
>      right now. Maybe a chance to use AI to generate a unit test for
> rte_flow.
>      This is important because it is a bug trap to add code that is not
> covered.