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