Acked-by: Vladimir Medvedkin <[email protected]>
On 10/9/2026 11:58 AM, Anatoly Burakov wrote:
Current implementation of flow engines in various drivers have a few issues that need to be corrected. For one, some of them 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]> ---
-- Regards, Vladimir
