From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: <dev@dpdk.org>, Ori Kam <orika@nvidia.com>,
Dariusz Sosnowski <dsosnowski@nvidia.com>
Subject: Re: [PATCH v1 01/21] ethdev: add flow graph API
Date: Wed, 26 Aug 2026 12:20:37 +0200 [thread overview]
Message-ID: <64e2bbcc-b77e-4b2c-9997-c99553486d0a@intel.com> (raw)
In-Reply-To: <nA_0NtHGRc2CE05D7MYfOw@monjalon.net>
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
next prev parent reply other threads:[~2026-08-26 10:20 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-20 14:00 [PATCH v1 00/21] Building a better rte_flow parser Anatoly Burakov
2026-08-20 14:00 ` [PATCH v1 01/21] ethdev: add flow graph API Anatoly Burakov
2026-08-25 13:55 ` Thomas Monjalon
2026-08-26 8:58 ` Burakov, Anatoly
2026-08-26 9:21 ` Thomas Monjalon
2026-08-26 9:26 ` Bruce Richardson
2026-08-26 10:20 ` Burakov, Anatoly [this message]
2026-08-26 14:46 ` Thomas Monjalon
2026-08-27 7:58 ` Burakov, Anatoly
2026-08-27 8:02 ` Thomas Monjalon
2026-08-20 14:00 ` [PATCH v1 02/21] net/intel/common: add flow engines infrastructure Anatoly Burakov
2026-08-20 14:00 ` [PATCH v1 03/21] net/intel/common: add utility functions Anatoly Burakov
2026-08-20 14:00 ` [PATCH v1 04/21] net/ixgbe: add support for common flow parsing Anatoly Burakov
2026-08-20 14:00 ` [PATCH v1 05/21] net/ixgbe: reimplement ethertype parser Anatoly Burakov
2026-08-20 14:00 ` [PATCH v1 06/21] net/ixgbe: reimplement syn parser Anatoly Burakov
2026-08-20 14:00 ` [PATCH v1 07/21] net/ixgbe: reimplement L2 tunnel parser Anatoly Burakov
2026-08-20 14:00 ` [PATCH v1 08/21] net/ixgbe: reimplement ntuple parser Anatoly Burakov
2026-08-20 14:00 ` [PATCH v1 09/21] net/ixgbe: reimplement security parser Anatoly Burakov
2026-08-20 14:00 ` [PATCH v1 10/21] net/ixgbe: reimplement FDIR parser Anatoly Burakov
2026-08-20 14:00 ` [PATCH v1 11/21] net/ixgbe: reimplement hash parser Anatoly Burakov
2026-08-20 14:00 ` [PATCH v1 12/21] net/i40e: add support for common flow parsing Anatoly Burakov
2026-08-20 14:00 ` [PATCH v1 13/21] net/i40e: reimplement ethertype parser Anatoly Burakov
2026-08-20 14:00 ` [PATCH v1 14/21] net/i40e: reimplement FDIR parser Anatoly Burakov
2026-08-20 14:01 ` [PATCH v1 15/21] net/i40e: reimplement tunnel QinQ parser Anatoly Burakov
2026-08-20 14:01 ` [PATCH v1 16/21] net/i40e: reimplement VXLAN parser Anatoly Burakov
2026-08-20 14:01 ` [PATCH v1 17/21] net/i40e: reimplement NVGRE parser Anatoly Burakov
2026-08-20 14:01 ` [PATCH v1 18/21] net/i40e: reimplement MPLS parser Anatoly Burakov
2026-08-20 14:01 ` [PATCH v1 19/21] net/i40e: reimplement gtp parser Anatoly Burakov
2026-08-20 14:01 ` [PATCH v1 20/21] net/i40e: reimplement L4 cloud parser Anatoly Burakov
2026-08-20 14:01 ` [PATCH v1 21/21] net/i40e: reimplement hash parser Anatoly Burakov
2026-08-21 15:27 ` [PATCH v1 00/21] Building a better rte_flow parser Stephen Hemminger
2026-09-08 15:20 ` [PATCH v2 00/19] " Anatoly Burakov
2026-09-08 15:20 ` [PATCH v2 01/19] ethdev: add flow graph API Anatoly Burakov
2026-09-08 15:20 ` [PATCH v2 02/19] net/intel/common: add flow engines infrastructure Anatoly Burakov
2026-09-08 15:20 ` [PATCH v2 03/19] net/intel/common: add utility functions Anatoly Burakov
2026-09-08 15:20 ` [PATCH v2 04/19] net/ixgbe: add support for common flow parsing Anatoly Burakov
2026-09-08 15:20 ` [PATCH v2 05/19] net/ixgbe: reimplement ethertype parser Anatoly Burakov
2026-09-08 15:20 ` [PATCH v2 06/19] net/ixgbe: reimplement syn parser Anatoly Burakov
2026-09-08 15:20 ` [PATCH v2 07/19] net/ixgbe: reimplement L2 tunnel parser Anatoly Burakov
2026-09-08 15:20 ` [PATCH v2 08/19] net/ixgbe: reimplement ntuple parser Anatoly Burakov
2026-09-08 15:20 ` [PATCH v2 09/19] net/ixgbe: reimplement security parser Anatoly Burakov
2026-09-08 15:20 ` [PATCH v2 10/19] net/ixgbe: reimplement FDIR parser Anatoly Burakov
2026-09-08 15:20 ` [PATCH v2 11/19] net/ixgbe: reimplement hash parser Anatoly Burakov
2026-09-08 15:20 ` [PATCH v2 12/19] net/ixgbe: advertise flow keep capability Anatoly Burakov
2026-09-08 15:20 ` [PATCH v2 13/19] net/i40e: add support for common flow parsing Anatoly Burakov
2026-09-08 15:20 ` [PATCH v2 14/19] net/i40e: reimplement ethertype parser Anatoly Burakov
2026-09-08 15:20 ` [PATCH v2 15/19] net/i40e: refactor FDIR engine infrastructure Anatoly Burakov
2026-09-08 15:20 ` [PATCH v2 16/19] net/i40e: reimplement FDIR parser Anatoly Burakov
2026-09-08 15:20 ` [PATCH v2 17/19] net/i40e: reimplement tunnel parsers Anatoly Burakov
2026-09-08 15:21 ` [PATCH v2 18/19] net/i40e: reimplement hash parser Anatoly Burakov
2026-09-08 15:21 ` [PATCH v2 19/19] net/i40e: advertise flow keep capability Anatoly Burakov
2026-09-09 9:08 ` [PATCH v2 00/19] Building a better rte_flow parser Burakov, Anatoly
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=64e2bbcc-b77e-4b2c-9997-c99553486d0a@intel.com \
--to=anatoly.burakov@intel.com \
--cc=dev@dpdk.org \
--cc=dsosnowski@nvidia.com \
--cc=orika@nvidia.com \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.