On Fri, 22 May 2026 17:27:26 +0200 Lukáš Šišmiš <[email protected]> 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
