> 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
