[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?
>> 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.
>>
>> For another, a lot of them are needlessly complicated and rely on a
>> separation between patterns and parsing that is hard to reason about and
>> maintain: they do not define memory ownership model, they do not 
>> define the
>> way in which we approach parameter and pattern parsing, and they
>> occasionally do weird things like passing around pointers-to-void- 
>> pointers
>> or even using pointers as integer values.
>>
>> Another common problem is extremely convoluted internal tracking, flow
>> installation, flow replay, and cleanup code. This infrastructure is 
>> usually
>> done in an ad-hoc manner that has a lot of boilerplate.
>>
>> These issues can be corrected, but because of how much code there is 
>> to the
>> current infrastructure and how tightly coupled it is, it would be 
>> easier to
>> just build new one from scratch, and gradually migrate all engines to use
>> it. This patch is intended as a first step towards that goal, and defines
>> both common data types to be used by all rte_flow parsers, as well as the
>> interaction model that is to be followed by all drivers.
>>
>> We define a set of structures that will represent:
>>
>> - Defined rte_flow parsing interaction model and code flow (ops struct)
>> - Defined memory allocation and ownership model for all engines
>> - Scratch space format for all engines (variably allocated typed struct)
>> - Flow rule format for all engines (variably allocated typed struct)
>> - Engine definitions that are compatible with secondary process model
>> - Implementations of common rte_flow operations
>> - Various supporting infrastructure for parser customization, e.g. hooks
>> - Support for using custom allocation (e.g. for mempool-based alloc)
>> - Support for replaying all flows to restore HW state
>> - Support for removing all flows without modifying HW state
>>
>> The design intent is heavily documented right inside the header and is to
>> be considered authoritative design document for how to build rte_flow
>> parsers for Intel Ethernet drivers going forward.
>>
>> Signed-off-by: Anatoly Burakov<anatoly.burakov at intel.com>
>> ---

<snip>

>> +    /* allocate context */
>> +    ctx = (struct ci_flow_engine_ctx *)calloc(1,
>> +            RTE_MAX(engine->ctx_size, sizeof(struct 
>> ci_flow_engine_ctx)));
>> +    if (ctx == NULL) {
>> +        return rte_flow_error_set(error, ENOMEM,
>> +                RTE_FLOW_ERROR_TYPE_HANDLE, NULL,
>> +                "Failed to allocate memory for rule engine context");
>> +    }
>> +    ctx->dev_data = engine_conf->dev_data;
>> +    ctx->attr = attr;
>> +    ctx->pattern = pattern;
>> +    ctx->actions = actions;
>> +    flow->dev_data = engine_conf->dev_data;

> it was set in ci_flow_alloc()

flow_alloc might not be called (e.g. for validate).

-- 
Thanks,
Anatoly