From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id D50FC20F for ; Thu, 18 May 2017 22:32:00 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2A9CF208A9; Thu, 18 May 2017 16:31:59 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 18 May 2017 16:31:59 -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=/2ElT7NWLbJPCbp sHUXoSeY4I7/3ePoRN57W1P0+sx4=; b=S3qBMjmYXTciuXarhIAlIcqqcrcp1/d CXBA4C6lWYRtZFqOXEUchz1ZdwEv+ZAFraDRylqaVzRkQFXKKo3KyT3KmUZfGSnC RoD4CdnmW6pyaNE/sCfMfYN2XwurBNyOAm7iXZ5Tc7v3LMuJ8hbEtU+q0UhutjY3 Z9g5y21CzvTc= 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=/2ElT7NWLbJPCbpsHUXoSeY4I7/3ePoRN57W1P0+sx4=; b=W1COwZc9 vuoTASrg5Q0feSj9E0IUUFUoY4s5ecjsmMFsGCcS1G3Pq/mWoSkrdgR1pCq4vrUM Ti4jZri/w5y9POOxA1CnuCrRo9m0bV/Py1Td+DhTknQMIwQqfRQCQBMByvdfhYBr 8XmIutf0gdARjJgewmE4i4lw5gq7+/ZmnEIr/+kvjkc8ugtWRQ+vWvx7B1fdaSPn ZrFPdeEdcVBOww+OsrC7/joplECTcjjnYAcvobEp3EgZ+UVoBE5KWFLsZy2NLHkf i653YFk6vTOAxVIo08HFvS0h5aXUaS1dx6MDF3WRsd9QqccnQXFgYVWgvqw8LtlY zddlFuE/qshAig== X-ME-Sender: X-Sasl-enc: aJjXDnmu5nVZDgdisUtbNY6x5KFZ9K8pVUGtMscSpDML 1495139518 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id A2B0924753; Thu, 18 May 2017 16:31:58 -0400 (EDT) From: Thomas Monjalon To: Ferruh Yigit Cc: dev@dpdk.org, =?ISO-8859-1?Q?Ga=EBtan?= Rivet , "Ananyev, Konstantin" , "Mcnamara, John" , "Tahhan, Maryam" , adrien.mazarguil@6wind.com Date: Thu, 18 May 2017 22:31:57 +0200 Message-ID: <2028578.MMgbIyi7hy@xps> In-Reply-To: References: <20170420185448.19162-1-ferruh.yigit@intel.com> <20170517163848.GQ14914@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 20:32:01 -0000 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 flexi= ble > > 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. > >=20 > > 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 not > > require rte_flow supports from the PMDs they would be using, only > > rte_flow_item parsing from the rte_flow_classify library. > >=20 > > 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. >=20 > Thanks for clarification, I see now what you and Konstantin is proposing. >=20 > And yes it makes sense to use rte_flow to define flows in the library, 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?