[PATCH v7 00/25] Building a better rte_flow parser

[Bruce Richardson]

On Tue, Oct 13, 2026 at 01:02:58PM +0100, Anatoly Burakov wrote:
> Most rte_flow parsers in DPDK suffer from huge implementation complexity because
> even though 99% of what people use rte_flow parsers for is parsing protocol
> graphs, no parser is written explicitly as a graph. This patchset attempts to
> suggest a viable model to build rte_flow parsers as graphs, by offering a
> library to build rte_flow parser graphs without too much boilerplate and
> complexity.
> 
> Most of the patchset is about Intel drivers, but they are meant as
> reimplementations as well as examples for the rest of the community to assess
> how to build parsers using this new infrastructure. I expect the first three
> patches will be of most interest to non-Intel reviewers, as they deal with
> building two reusable parser architecture pieces.
> 
> The first piece is a new flow graph helper in ethdev. Its purpose is
> deliberately narrow: it targets the protocol-graph part of rte_flow pattern
> parsing, where drivers walk packet headers and validate legal item sequences and
> parameters. That does not cover all possible rte_flow features, especially more
> exotic flow items, but it does cover a large and widely shared part of what
> existing drivers need to do. Or, to put it in other words, the only flow items
> this infrastructure *doesn't* cover is things that do not lend themselves well
> to be parsed as a graph of protocol headers (e.g. conntrack items). Everything
> else should be covered or cover-able. In practice, just about all drivers will
> benefit from graph parsing as all but one of them implement only the protocol
> stack parts, which are the ones targeted by the graph helper.
> 
> The second piece is a reusable flow engine framework for Intel Ethernet drivers.
> This is kept Intel-local because I do not feel it is even appropriate to define
> such a framework for all drivers to use in the first place. Even so, the intent
> is to establish a cleaner parser architecture with a defined interaction model,
> explicit memory ownership rules, locking, initialization sequence,
> implementations of rte_flow API entry points, flow replay and memory cleanup,
> and engine definitions that do not block secondary-process-safe usage. It is my
> hope that this would serve as a model for other drivers to follow, expand on,
> rework, and improve, so that maybe down the line we *might* have a common
> rte_flow infrastructure for drivers to use.
> 
> Most of the rest of the series is parser reimplementation, but that is mainly
> the vehicle for demonstrating and validating those two pieces. ixgbe and i40e
> are wired into the new common parsing path, and their existing parsers are
> migrated incrementally to the graph-based model. Besides reducing ad hoc parser
> code, this also makes validation more explicit and more consistent. In a few
> places that means invalid inputs that were previously ignored, deferred, or
> interpreted loosely are now rejected earlier and more strictly, without any
> increase in code complexity (in fact, with marked *decrease* of it!).
> 
> v6 -> v7:
> - Validate graph nodes only once, including start node
> - Stop trying new engines when context allocation fails
> - Typos/copyright year changes
> - Fixed ixgbe ethertype skipping over stale entries
> - Fixed ixgbe ntuple to correctly handle L4 protocols when they are not zero
> - Fixed ixgbe fdir to mask out impossible bits from the rule
> - Fixed ixgbe security engine only deleting first SA table entry
> - Reworked i40e ORT programming because these registers are global
> - Fixed i40e RSS validation to handle GTP protocols correctly
> - Fixed hash table names being too long in some cases
> 

Patchset applied to dpdk-next-net-intel.

As well as the arm build issue, I also fixed a number of checkpatch issues,
since there were a large number on this set. Most I kept unfixed, since I
felt the exceptions were reasonable, but please check what was applied in
case some issue was introduced with the checkpatch changes I made on apply.

Thanks,
/Bruce