From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id B30E02C5 for ; Fri, 19 May 2017 10:57:06 +0200 (CEST) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 May 2017 01:57:05 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.38,363,1491289200"; d="scan'208";a="263929352" Received: from irsmsx110.ger.corp.intel.com ([163.33.3.25]) by fmsmga004.fm.intel.com with ESMTP; 19 May 2017 01:57:03 -0700 Received: from irsmsx155.ger.corp.intel.com (163.33.192.3) by irsmsx110.ger.corp.intel.com (163.33.3.25) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 19 May 2017 09:57:03 +0100 Received: from irsmsx109.ger.corp.intel.com ([169.254.13.12]) by irsmsx155.ger.corp.intel.com ([169.254.14.202]) with mapi id 14.03.0319.002; Fri, 19 May 2017 09:57:02 +0100 From: "Ananyev, Konstantin" To: Thomas Monjalon , "Yigit, Ferruh" CC: "dev@dpdk.org" , =?iso-8859-1?Q?Ga=EBtan_Rivet?= , "Mcnamara, John" , "Tahhan, Maryam" , "adrien.mazarguil@6wind.com" Thread-Topic: [dpdk-dev] [RFC 17.08] flow_classify: add librte_flow_classify library Thread-Index: AQHSzycWQ0k8i1G2ske7ihNZHerxZ6H4qQsAgAE9EgCAAJZngIAA4KjA Date: Fri, 19 May 2017 08:57:01 +0000 Message-ID: <2601191342CEEE43887BDE71AB9772583FAF803F@IRSMSX109.ger.corp.intel.com> References: <20170420185448.19162-1-ferruh.yigit@intel.com> <20170517163848.GQ14914@bidouze.vm.6wind.com> <2028578.MMgbIyi7hy@xps> In-Reply-To: <2028578.MMgbIyi7hy@xps> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [RFC 17.08] flow_classify: add librte_flow_classify library X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 08:57:07 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas@monjalon.net] > Sent: Thursday, May 18, 2017 9:32 PM > To: Yigit, Ferruh > Cc: dev@dpdk.org; Ga=EBtan Rivet ; Ananyev, Konst= antin ; Mcnamara, John > ; Tahhan, Maryam ; adri= en.mazarguil@6wind.com > Subject: Re: [dpdk-dev] [RFC 17.08] flow_classify: add librte_flow_classi= fy library >=20 > 18/05/2017 13:33, Ferruh Yigit: > > On 5/17/2017 5:38 PM, Ga=EBtan Rivet wrote: > > > The other is the expression of flows through a shared syntax. Using > > > flags to propose presets can be simpler, but will probably not be fle= xible > > > enough. rte_flow_items are a first-class citizen in DPDK and are > > > already a data type that can express flows with flexibility. As > > > mentioned, they are however missing a few elements to fully cover IPF= IX > > > meters, but nothing that cannot be added I think. > > > > > > So I was probably not clear enough, but I was thinking about > > > supporting rte_flow_items in rte_flow_classify as the possible key > > > applications would use to configure their measurements. This should n= ot > > > require rte_flow supports from the PMDs they would be using, only > > > rte_flow_item parsing from the rte_flow_classify library. > > > > > > Otherwise, DPDK will probably end up with two competing flow > > > representations. Additionally, it may be interesting for applications > > > to bind these data directly to rte_flow actions once the > > > classification has been analyzed. > > > > Thanks for clarification, I see now what you and Konstantin is proposin= g. > > > > And yes it makes sense to use rte_flow to define flows in the library, = I > > will update the RFC. >=20 > Does it mean that rte_flow.h must be moved from ethdev to this > new flow library? Or will it depend of ethdev? Just a thought: probably move rte_flow.h to lib/librte_net? Konstantin