On Fri, 28 Apr 2023 17:04:46 -0700 Stephen Hemminger <[email protected]> wrote:
> On Fri, 28 Apr 2023 12:13:26 -0700 > Cliff Burdick <[email protected]> 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).
