On 8/26/2026 4:46 PM, Thomas Monjalon wrote:
26/08/2026 12:20, Burakov, Anatoly:
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?
I don't think adding eth prefix is needed.
[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?]
Yes vfio_driver looks fine.
Actually, on second thought, "vfio_driver" is too similar to
"bus_driver" and "dev_driver" which kind of implies that "vfio_driver"
is for writing vfio drivers. Maybe dev_vfio would be better?
(flow_driver sits in lib/ethdev which is a driver subsystem, but vfio
sits in EAL which is not, so for flow_driver I think "flow_driver" is
OK, but vfio header is in common include together with bus_driver and
dev_driver, I think vfio_driver would be confusing)
--
Thanks,
Anatoly
