From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <thomas@monjalon.net> Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 8955E1F5 for <dev@dpdk.org>; Fri, 19 May 2017 12:11:55 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2495D208EF; Fri, 19 May 2017 06:11:55 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 19 May 2017 06:11:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=3SH2pbpF0v3rQie PGex4cix6svHE7nAHzyqB4JNiWaY=; b=CppiH2TfPaAnUmOU2N8Rv/jHYSzNhjt m2XgLazStbSfTU9ycrUN+c/DFNvONjOJj+ZL5AHp04eCPD5otTyJsFhr4YQ3s7RD uLh3bDCayxv6yFBCvpn0mo9qRiK0+xUGAc+tc35AMt4eX0DuwoUt6kVOe6BPXjXz SVE7cqz3BKk0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=3SH2pbpF0v3rQiePGex4cix6svHE7nAHzyqB4JNiWaY=; b=ZXplrptH I3UwaJqcUTWf2Lvh5yCck3j9XErncGvihYaRYzOM2WFz1rvjxcjnOzGS49q3XpYu 2h78EbVY7qzCs64QEimqjJUsr3X3tkSv+PC2nIoeOh0Xzw+FDqjeQ7oi3sgPZFsv g3vf6LZe8idbjCQwYKSvwMl9asNgSxEzwDPVAy5T8ycovKhlnZB/FunuS80V+Bno 4NYjMprTwh3VBtf6yN0h/N8wgEmTzemK8HedLZbQ2pJCFojyha5dQ2GUXGBqWQaQ 407+ewmpp8aEMCcua4Y107hGa2/J8m+hU1IvVmecvY1219U1VZ6hebcYktnrn83t O0i+Y3f+VoLRLQ== X-ME-Sender: <xms:68QeWVXBuux25DqdP4vqElEQTMAt-KiGB2QSRYMPxmBmC-OYqts87Q> X-Sasl-enc: Ye0rlAc1lJLf+BTiz8ZXwf9e25Q6FmQhK8bIyqJ82POK 1495188714 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id CA8902475E; Fri, 19 May 2017 06:11:54 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: =?ISO-8859-1?Q?Ga=EBtan?= Rivet <gaetan.rivet@6wind.com>, "Ananyev, Konstantin" <konstantin.ananyev@intel.com>, "Yigit, Ferruh" <ferruh.yigit@intel.com> Cc: dev@dpdk.org, "Mcnamara, John" <john.mcnamara@intel.com>, "Tahhan, Maryam" <maryam.tahhan@intel.com>, "adrien.mazarguil@6wind.com" <adrien.mazarguil@6wind.com> Date: Fri, 19 May 2017 12:11:53 +0200 Message-ID: <3128026.nHak02edMh@xps> In-Reply-To: <20170519091127.GY14914@bidouze.vm.6wind.com> References: <20170420185448.19162-1-ferruh.yigit@intel.com> <2601191342CEEE43887BDE71AB9772583FAF803F@IRSMSX109.ger.corp.intel.com> <20170519091127.GY14914@bidouze.vm.6wind.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" 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 <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Fri, 19 May 2017 10:11:55 -0000 19/05/2017 11:11, Ga=EBtan Rivet: > On Fri, May 19, 2017 at 08:57:01AM +0000, Ananyev, Konstantin wrote: > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > >> 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 = flexible > >> > > 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 = IPFIX > >> > > 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 shoul= d not > >> > > 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 applicati= ons > >> > > 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 propo= sing. > >> > > >> > And yes it makes sense to use rte_flow to define flows in the librar= y, I > >> > will update the RFC. > >> > >> Does it mean that rte_flow.h must be moved from ethdev to this > >> new flow library? Or will it depend of ethdev? >=20 > Even outside of lib/librte_ether, wouldn't rte_flow stay dependent on > rte_ether? >=20 > > > >Just a thought: probably move rte_flow.h to lib/librte_net? > >Konstantin >=20 > If we are to move rte_flow, why not lib/librte_flow? There are 3 different things: 1/ rte_flow.h for flow description 2/ rte_flow API in ethdev for HW offloading 3/ SW flow table (this new lib) 2 and 3 will depends on 1. I think moving rte_flow.h in librte_net is a good idea.