<div dir="ltr"><div dir="ltr"> </div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Apr 30, 2023 at 3:10 AM Thomas Monjalon <<a href="mailto:thomas@monjalon.net">thomas@monjalon.net</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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 < > <a href="mailto:stephen@networkplumber.org" target="_blank">stephen@networkplumber.org</a>> wrote: > > > On Fri, 28 Apr 2023 12:13:26 -0700 > > Cliff Burdick <<a href="mailto:shaklee3@gmail.com" target="_blank">shaklee3@gmail.com</a>> 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? <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div> </div>+1 It would be definitely useful to have a generic parser which could re-use the test-pmd parser code as it has already done the heavy lifting. I would be happy to contribute/help to get this going. </blockquote> </blockquote></div></div>