This thread is an API suggestion, it should be discussed in the developer mailing list (did the Cc here).
29/04/2023 16:23, Cliff Burdick: > > Would rather the flow parser was rewritten as well. Doing open coded > > parser is much more error prone and hard to extend versus writing the > > parser in yacc/lex (ie bison/flex). > > I agree, and that's kind of why the original suggestion of using testpmd > came from. Writing a new parser is obviously the better choice and would > have been great if testpmd started that way, but a significant amount of > time was invested in that method. Since it works and is tested, it didn't > seem like a bad request to build off that and bring that code into an rte_ > API. I'd imagine building a proper parser would not just require the parser > piece, but also making sure all the tests now use that, and also the legacy > testpmd was converted. It seemed unlikely all of this could be done in a > reasonable amount of time and a lot of input from many people. Given the > amount of debugging I (and others) have spent on figuring on why a flow > spec didn't work properly, this could be a huge timesaver for new projects > like Tom mentioned. > > On Fri, Apr 28, 2023 at 5:04 PM Stephen Hemminger < > step...@networkplumber.org> wrote: > > > On Fri, 28 Apr 2023 12:13:26 -0700 > > Cliff Burdick <shakl...@gmail.com> wrote: > > > > > Hi Stephen, it would definitely not be worthwhile to repeat everything > > > that's already tested with testpmd. I was thinking that given that there > > > already is a "flow_parse" function that does almost everything needed, > > > something like that could be exposed. If we think of the testpmd flow > > > string as a sort of "IR" for string flow specification, that would allow > > > others to implement higher-level transform of a schema like JSON or YAML > > > into the testpmd language. Due to the complexity of testpmd and how it's > > > the source of true for testing flows, I think it's too great of an ask to > > > have testpmd support a new type of parsing. My only suggestion would be > > > to take what already exists and expose it in a public API that is included > > > in a DPDK install. So the only things we need are 2 functions, if I understand well: int rte_flow_to_text(const struct rte_flow*); struct rte_flow *rte_flow_from_text(const char *); Here I assume the output of rte_flow_from_text() would be a created flow, meaning it calls rte_flow_create() under the hood. Is it what you wish? Or should it fill port ID, attributes, patterns and actions?