On Sat, Apr 29, 2023 at 2:49 PM Cliff Burdick <shakl...@gmail.com> wrote:
> > So the only things we need are 2 functions, if I understand well: > > > > int rte_flow_to_text(const struct rte_flow*); > > struct rte_flow *rte_flow_from_text(const char *); > > > > Here I assume the output of rte_flow_from_text() would be a created flow, > > meaning it calls rte_flow_create() under the hood. > > Is it what you wish? > > Or should it fill port ID, attributes, patterns and actions? > > > > I think it should follow closely with what "flow_parse" already does: > https://github.com/DPDK/dpdk/blob/d03446724972d2a1bb645ce7f3e64f5ef0203d61/app/test-pmd/cmdline_flow.c#L11304 > > > > Namely, just do the part of populating attributes, patterns, and actions > from a string. It's then up to the user if they want to create, validate, > or do something else with it (like see how it populate> d the structures). > The flow_parse function appears to take an opaque pointer that's specific > to a structure inside of cmdline_flow.c and assign the attributes, actions, > and patterns to members of that result struct. I don't know the reason for > this, but when >calling the function the user doesn't know how many > patterns or actions their string will generate. They would either need to > pass in structures that are allocated larger than needed, or have a > separate API that returns how many actions and patterns are needed for a > string, then they need to allocate the correct size themselves. I'm > assuming it's not ideal to have the library itself do dynamic memory > allocations for the correct size. > >> >> Tom, for what it's worth I'm on a quest to get this to work since I think it's necessary. I'm just hacking through it like you did and I ran into the same "template" keyword error. It's probably worthwhile to fix that anyways. I'm maintaining a set of patches as I go. The general strategy has been to remove testpmd's main function, compile it as a library, and link against that.
