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