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<[email protected]>
---
<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
