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.
/Bruce
