From mboxrd@z Thu Jan 1 00:00:00 1970 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) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga102.fm.intel.com with ESMTP; 17 Nov 2016 22:36:34 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.31,655,1473145200"; d="scan'208";a="32705542" Received: from fmsmsx108.amr.corp.intel.com ([10.18.124.206]) by orsmga005.jf.intel.com with ESMTP; 17 Nov 2016 22:36:34 -0800 Received: from fmsmsx126.amr.corp.intel.com (10.18.125.43) by FMSMSX108.amr.corp.intel.com (10.18.124.206) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 17 Nov 2016 22:36:34 -0800 Received: from shsmsx152.ccr.corp.intel.com (10.239.6.52) by FMSMSX126.amr.corp.intel.com (10.18.125.43) with Microsoft SMTP Server (TLS) id 14.3.248.2; Thu, 17 Nov 2016 22:36:33 -0800 Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.239]) by SHSMSX152.ccr.corp.intel.com ([169.254.6.138]) with mapi id 14.03.0248.002; Fri, 18 Nov 2016 14:36:31 +0800 From: "Xing, Beilei" To: Adrien Mazarguil , "dev@dpdk.org" CC: Thomas Monjalon , "De Lara Guarch, Pablo" , Olivier Matz Thread-Topic: [dpdk-dev] [PATCH 01/22] ethdev: introduce generic flow API Thread-Index: AQHSQCYA6uPnKzV+6EK5TAIQEgT0dqDeN0Rw 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> In-Reply-To: <1c8a8e4fec73ed33836f1da9525b1b8b53048518.1479309720.git.adrien.mazarguil@6wind.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 01/22] ethdev: introduce generic flow API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 06:36:37 -0000 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