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
