On Sun, Apr 30, 2023 at 3:10 AM Thomas Monjalon <thomas@monjalon.net> wrote:

> 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 <
> > stephen@networkplumber.org> wrote:
> >
> > > On Fri, 28 Apr 2023 12:13:26 -0700
> > > Cliff Burdick <shaklee3@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?
>
>
>> +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.
>>
>