Generic flow string parser

[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 at networkplumber.org> wrote:

> On Fri, 28 Apr 2023 12:13:26 -0700
> Cliff Burdick <shaklee3 at 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.
> >
> > If you look at the "flow_classify" example in DPDK you can already see
> that
> > for that application someone had to write another flow text parser for a
> > format they made up. Instead, that example could be converted over to
> this
> > other API as well.
>
> Please don't top post.
>
> The naming issue is that almost all libraries in DPDK start with rte_
> prefix
> and the testpmd functions do not.
>
> The flow_classify example is pretty much abandonware at this point.
> Code is not updated, other than build breakages.
> Last time I looked at it noticed lots of code reinvention useless code,
> and only supports IPv4. It really needs a rewrite.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mails.dpdk.org/archives/users/attachments/20230429/cc90fe83/attachment.htm>