Generic flow string parser

[Stephen Hemminger]

On Fri, 28 Apr 2023 17:04:46 -0700
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.

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