Sure. I will add some tests.
> -----Original Message----- > From: Stephen Hemminger <[email protected]> > Sent: Friday, February 6, 2026 12:43 AM > To: Bing Zhao <[email protected]> > Cc: Slava Ovsiienko <[email protected]>; [email protected]; Raslan > Darawsheh <[email protected]>; Ori Kam <[email protected]>; Dariusz > Sosnowski <[email protected]>; Suanming Mou <[email protected]>; > Matan Azrad <[email protected]>; NBU-Contact-Thomas Monjalon (EXTERNAL) > <[email protected]> > 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 <[email protected]> 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 <[email protected]> > > --- > > 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.
