[dpdk-dev] [PATCH 01/22] ethdev: introduce generic flow API

Xing, Beilei beilei.xing at intel.com
Fri Nov 18 07:36:31 CET 2016

Hi Adrien,

> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Adrien Mazarguil
> Sent: Thursday, November 17, 2016 12:23 AM
> To: dev at dpdk.org
> Cc: Thomas Monjalon <thomas.monjalon at 6wind.com>; De Lara Guarch,
> Pablo <pablo.de.lara.guarch at intel.com>; Olivier Matz
> <olivier.matz at 6wind.com>
> Subject: [dpdk-dev] [PATCH 01/22] ethdev: introduce generic flow API
> This new API supersedes all the legacy filter types described in rte_eth_ctrl.h.
> It is slightly higher level and as a result relies more on PMDs to process and
> validate flow rules.
> Benefits:
> - A unified API is easier to program for, applications do not have to be
>   written for a specific filter type which may or may not be supported by
>   the underlying device.
> - The behavior of a flow rule is the same regardless of the underlying
>   device, applications do not need to be aware of hardware quirks.
> - Extensible by design, API/ABI breakage should rarely occur if at all.
> - Documentation is self-standing, no need to look up elsewhere.
> Existing filter types will be deprecated and removed in the near future.
> Signed-off-by: Adrien Mazarguil <adrien.mazarguil at 6wind.com>

> +
> +/**
> + * Opaque type returned after successfully creating a flow.
> + *
> + * This handle can be used to manage and query the related flow (e.g.
> +to
> + * destroy it or retrieve counters).
> + */
> +struct rte_flow;
> +

As we talked before, we use attr/pattern/actions to create and destroy a flow in PMD, 
but I don't think it's easy to clone the user-provided parameters and return the result
to the application as a rte_flow pointer.  As you suggested:
/* PMD-specific code. */
 struct rte_flow {
    struct rte_flow_attr attr;
    struct rte_flow_item *pattern;
    struct rte_flow_action *actions;

Because both pattern and actions are pointers, and there're also pointers in structure
rte_flow_item and struct rte_flow_action. We need to iterate allocation during clone
and iterate free during destroy, then seems that the code is something ugly, right?

I think application saves info when creating a flow rule, so why not application provide
attr/pattern/actions info to PMD before calling PMD API?

Beilei Xing

More information about the dev mailing list