[PATCH v3 02/19] net/intel/common: add flow engines infrastructure

[Burakov, Anatoly]

On 9/19/2026 6:09 PM, Medvedkin, Vladimir wrote:
> 
> On 9/16/2026 1:18 PM, Anatoly Burakov wrote:
>> Current implementation of flow engines in various drivers have a few 
>> issues
>> that need to be corrected.
>>
>> For one, some of the
> seems like a missed word?

Not missed, typoed - should've been "them" not "the" :)

>> are fundamentally incompatible with secondary
>> processes, because the flow engine registration and creation will
>> allocate structures in shared memory but use process-local pointers to
>> point to flow engines and pattern tables.

<snip>

>> +
>> +    /* no engine could handle this flow */
>> +    CI_DRV_LOG(DEBUG, "no engine accepted the flow");
>> +    flow = NULL;
>> +    rte_flow_error_set(error, ENOTSUP,
>> +            RTE_FLOW_ERROR_TYPE_UNSPECIFIED, NULL,
>> +            "No flow engine could handle the requested flow");
> This unconditionally rewrites error string, don't we want to keep the 
> last reason why flow wasn't created? Same is applied for validate.

No, if no engine accepted the flow that means there are no meaningful 
error messages to be had here. If the pattern matching failed but 
should've succeeded, there is no way for us to tell whether it was 
*supposed to* succeed or whether this pattern genuinely needs a 
different engine. So, if no engine accepted the flow, we have no idea 
whether it's because the flow is genuinely unsupported, or because there 
is a bug in engine implementation.

In contrast, if the engine has accepted the flow (i.e. if *parsing* 
succeeded), then a failure on register/install is a genuine error, in 
which case we do not try other engines, and output a meaningful error 
message.

-- 
Thanks,
Anatoly