On Sat, Apr 29, 2023 at 2:49 PM Cliff Burdick <shaklee3@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.