RFCv1: DPDK RTE Flow Rule Parser

[Lukáš Šišmiš]

On 11/7/25 17:07, Stephen Hemminger wrote:
> On Fri, 7 Nov 2025 15:16:28 +0100
> Lukáš Šišmiš <sismis at cesnet.cz> 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.

Heh, I tried AI but failed, or rather it gave up -- at least for now.

I didn't know about the parsing tools, will give it a look, thanks!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5986 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mails.dpdk.org/archives/dev/attachments/20251110/4ae2e5f0/attachment-0001.bin>