Re: [RFC PATCH 0/3] flow_compile: textual flow rule compiler

[Stephen Hemminger <stephen@networkplumber.org>]

On Fri, 22 May 2026 17:27:26 +0200
Lukáš Šišmiš <sismis@dyna-nic.com> wrote:

> (My) original idea was to reuse one parser for both the testpmd and the
> library to avoid multiple implementations of essentially the same thing.
> 
> How would "flow compile" be useful if testpmd already has the "flow create"
> command? Perhaps as a library demo only? I would expect testpmd users to
> like the `flow create` endpoint more for its more comprehensive support.
> Similarly, at this moment, since testpmd supports interactivity, I cannot
> see how the `_compile` API would replace functions in testpmd. But perhaps
> it would be part of a greater effort to migrate to flex/bison solution.
> Since this is also a simple, single-rule, stateless parser, it is not fully
> compatible with all of TestPMD's commands (e.g., "set raw_encap"). (Ok,
> noticed, you highlighted this)
> Perhaps it is fine, just wanted to highlight this.
> 
> From the user-as-an-engineer's perspective, I would be generally happy for
> this parser to exist. The drop-filter feature in Suricata, in my view,
> requires just a simple network pattern specification so looking at the
> supported patterns already ticks off most of the items I've had in mind,
> except, e.g., MPLS. I can also see this as a viable way for Suricata
> user-specified decap options for better applicability of RSS.
> 


I am taking this is in a slightly different direction in next step.
The syntax of testpmd filters is just raw expression of what rte_flow items
are. The compiler should not need all the seperators and end marker.
It should be user friendly and hide the internals not expose them