On 8/26/2026 11:21 AM, Thomas Monjalon wrote:
26/08/2026 10:58, Burakov, Anatoly:
On 8/25/2026 3:55 PM, Thomas Monjalon wrote:
20/08/2026 16:00, Anatoly Burakov:
This commit adds a flow graph parsing API. This is a helper API intended to
help ethdev drivers implement rte_flow parsers, as common usages map to
graph traversal problem very well.

Features provided by the API:
- Flow graph, edge, and node definitions
- Graph traversal logic
- Declarative validation against common flow item types
- Per-node validation and state processing callbacks
[...]
   lib/ethdev/rte_flow_graph.h                 | 532 ++++++++++++++

Are we sure about the name? Why not "parsing" instead of "graph"?


Because it is intended to help build *protocol graphs*, not *generic
flow parsing*. I.e. only things that lend themselves to be represented
by a graph would work with this - things like conntrack wouldn't. So, I
feel like "graph" is a more accurate name for this, because this is only
for enabling the protocol graph walk, not for full flow parsing.

OK

Is it only for drivers? In this case, no need to make it a public API.

Yes, it is for drivers. It is not a public API, it is not installed into
public headers. If there is anything I forgot to do to remove it from
being public, please let me know.

You should not use the rte_ prefix for files which are not public.
I know this convention is not well followed for historical reason,
like rte_flow_driver.h should be flow_driver.h



The fact that it didn't look like there was no convention was why I picked rte_ prefix. I'll happily use a non-rte prefix for these. Maybe use eth_ prefix for both flow_graph and flow_driver? Or does flow_graph work fine?

[on a separate note: should rte_vfio follow suit and be renamed? it is no longer a public API following my patchset. renaming it to `vfio` would probably cause conflicts with Linux headers, so maybe something like vfio_driver like flow_driver?]

--
Thanks,
Anatoly

Reply via email to