On Fri, 7 Nov 2025 15:16:28 +0100 Lukáš Šišmiš <[email protected]> wrote:
> Hello all, > > ## Motivation > > Recent discussions on DPDK Slack raised the idea of extracting the > rte_flow rule parser currently embedded in dpdk-testpmd into a > standalone, reusable library [1]. > > The main motivation is that the external applications, such as Suricata > IDS [2], often need to express hardware filtering rules in a consistent > and human-readable format. > > When integrating rte_flow into Suricata [3], we encountered the lack of > a unified way to define such rules. The immediate need was to let users > specify input filters (drop/allow) determining which traffic should be > inspected. > > Suricata’s existing capture modes (e.g. AF-PACKET) rely on BPF filters > [4]. Maintaining consistency across Suricata capture backends would be > ideal, but BPF and rte_flow differ significantly in expressiveness. > > The other options include either dpdk-testpmd or custom rule syntax. To > not reinvent the wheel, I am leaning towards use of the testpmd syntax > for the ready-to-use generic expressibility, especiaily of the network > traffic patterns. For the reference, I am speaking of the rte_flow rule > syntax that you can define through testpmd CLI, e.g., "flow create 0 > ingress pattern eth / vlan vid is 0xabc / ipv4 src is 192.168.0.1 src is > 53 / tcp / end actions drop / end". > > In the Slack, Thomas Monjalon concluded that it is generally welcome to > see a new parser library but we need to state it is just one way how > create rte_flow C structures. (Fine by me) > > ## Library proposal > > The existing function flow_parse() in dpdk-testpmd already performs most > of the needed work: > > int > flow_parse(const char *src, void *result, unsigned int size, > struct rte_flow_attr **attr, > struct rte_flow_item **pattern, struct rte_flow_action **actions) > > It parses a rule expressed in testpmd syntax and initializes rte_flow > attributes, items, and actions. > External applications that use these structures directly can skip > redundant setup logic and rely on standard DPDK APIs (validate, create, > destroy). > > For a public API, the void *result and unsigned int size parameters > appear unnecessary and could be removed. The simplified interface would > only expose the meaningful outputs (attr, pattern, actions). > > ## Problem statement > > The main question is how to provide this parser without fragmenting > existing functionality. > > I would like to extract the existing code from dpdk-testpmd to have one > parser that is available and used by both testpmd and external apps > (using the library itself). > I quickly run into the complexity of the testpmd code and how entangled > the C structures are throughout the testpmd's source code. > While the parser extraction should be possible, I wanted to check here > with the community if that is the most preferred approach. > Since the extraction moves a lot of code from place to another, there is > a very good chance that it would break all forked custom testpmds. > > The other alternative is to "start simple" with an alternative > implementation, perhaps only focusing on subset of testpmd's parser > capabilities. But this would very likely lead to two places being > maintained independently. > > Before taking either route, I’d like to understand the community’s > preference: > - Do you even see it as a valuable contribution for customer applications? > - Can you possibly think of an alternative way to solve the unified > human-readable format conversion? Both on the code level and interface > level. > - Is testpmd code extraction the right long-term solution, even if > disruptive? Should the private DPDK forks be taken into consideration? > Or should I start with a separate lightweight parser and revisit > integration later? > > Any other feedback is welcome. > > > Thank you. > > All the best, > Lukas > > > [1] https://dpdkproject.slack.com/archives/CB2UPBU48/p1759765888891329 > [2] https://github.com/OISF/suricata > [3] https://github.com/OISF/suricata/pull/13950 > [4] https://docs.suricata.io/en/latest/performance/ignoring-traffic.html > > Seems like a good place to see what any of the AI tools can do. Would also be good to use standard parsing tools (lex + yacc) rather than doing all the parsing with open coded C string handling. Ignore private DPDK forks, we can't test them. If you build it they will come to the new code.
