From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Xing, Beilei" Subject: Re: [PATCH 01/22] ethdev: introduce generic flow API Date: Fri, 18 Nov 2016 06:36:31 +0000 Message-ID: <94479800C636CB44BD422CB454846E012EA1C37D@SHSMSX101.ccr.corp.intel.com> References: <1c8a8e4fec73ed33836f1da9525b1b8b53048518.1479309720.git.adrien.mazarguil@6wind.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: Thomas Monjalon , "De Lara Guarch, Pablo" , Olivier Matz To: Adrien Mazarguil , "dev@dpdk.org" Return-path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 6D17B5582 for ; Fri, 18 Nov 2016 07:36:35 +0100 (CET) In-Reply-To: <1c8a8e4fec73ed33836f1da9525b1b8b53048518.1479309720.git.adrien.mazarguil@6wind.com> Content-Language: en-US List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Adrien, > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Adrien Mazarguil > Sent: Thursday, November 17, 2016 12:23 AM > To: dev@dpdk.org > Cc: Thomas Monjalon ; De Lara Guarch, > Pablo ; Olivier Matz > > Subject: [dpdk-dev] [PATCH 01/22] ethdev: introduce generic flow API >=20 > 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 proces= s and > validate flow rules. >=20 > Benefits: >=20 > - 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. >=20 > - The behavior of a flow rule is the same regardless of the underlying > device, applications do not need to be aware of hardware quirks. >=20 > - Extensible by design, API/ABI breakage should rarely occur if at all. >=20 > - Documentation is self-standing, no need to look up elsewhere. >=20 > Existing filter types will be deprecated and removed in the near future. >=20 > Signed-off-by: Adrien Mazarguil > + > +/** > + * 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 fl= ow in PMD,=20 but I don't think it's easy to clone the user-provided parameters and retur= n 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 i= n structure rte_flow_item and struct rte_flow_action. We need to iterate allocation dur= ing 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 applic= ation provide attr/pattern/actions info to PMD before calling PMD API? Thanks, Beilei Xing