[RFC 1/3] flow_compile: introduce textual flow rule compiler

[Konstantin Ananyev]

> On Tue, May 05, 2026 at 08:29:55PM -0700, Stephen Hemminger wrote:
> > Currently the only way to compile a flow rule from text is to link
> > against testpmd's cmdline_flow.c, which is tightly coupled to
> > librte_cmdline and the testpmd command framework.  Recent attempts
> > to extract it as a library have produced ad-hoc copies rather than
> > a clean separation.
> >
> > Add librte_flow_compile, modelled on libpcap's pcap_compile(): a
> > textual rule goes in, an opaque compiled object comes out, and
> > diagnostics of the form "line:col: message" go in a caller-supplied
> > buffer.  Accessors return the rte_flow_attr/item/action arrays
> > ready for rte_flow_create(); a convenience entry point installs
> > the rule directly on a port.
> >
> > The parser is recursive descent driven by descriptor tables of
> > items and actions, so adding a new item type is purely a table
> > edit -- the parser has no per-type knowledge.  A custom-setter
> > hook handles fields whose layout cannot be expressed as a plain
> > byte range (bitfields, indirect arrays).
> >
> > Dependencies are limited to rte_ethdev and rte_net; no
> > librte_cmdline, no flex/bison, no platform-specific headers.
> > The grammar follows testpmd's syntax so familiar rules carry
> > over and is documented in the programmer's guide.
> >
> Was there a particular reason to avoid using flex/bison here, or did their
> use just not make sense? In general I would prefer using code-generation
> tools where possible rather than maintaining (metaphorically) hand-written
> code.

In general, I like the idea of flow_compile(const char *) and the idea to make
it independent from cmdline lib.
Though I have the same question as Bruce: why not to use flex/bison here?
At first glance, that's the right tools for that kind of job and seems much better
then hand-written (AI generated) peace of code that no-one would probably understand. 
Konstantin