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 DC8EF9FE for ; Thu, 5 Oct 2017 00:42:54 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 7F48E20C75; Wed, 4 Oct 2017 18:42:54 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 04 Oct 2017 18:42:54 -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=cMIglExFSx1r9uQ nRgYWSXkhZN2YmTrOA7ZL1Pyko/g=; b=UI+yJyxo2+CiWSmu1iPvYYRMfZFkt3k BQhe9iNPaZ6NEpTz/g9Wm4GRc+hI4DiEFckRgr1esk/fkT9W6PHZ+GPDF1m+lQHz cKrDPilAhx5ZvOATh2jlf0IbBsbjwjtfPL/g7VNcHMHVKyhzxbWJ7UJ2BrsWGvNw koDydStON9sg= 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=cMIglExFSx1r9uQnRgYWSXkhZN2YmTrOA7ZL1Pyko/g=; b=JHt1Hxgc 72JV51Wn92I3/fhO8AY4qrrfi35NUWVx4LELofoud5JOzd4FPNPqaXrXEL/fZnvh UWZonqYM7KcC82NCFLfpc//tVmoo6tLSH9Qb7U/S9IomEqBlOmMOEmtZza9miMeW b2rZNCTYITIaA9zmZoJFmckuOFM6CZLBmonj0SrnH3aVk7KfqWEm/t1abDfqO56P LOQ2AcXKggb3vMOuwJL9HtRa0EcoUevI5H4GFZ4FwHBKmN8yKb06FJp7IPhKCWdF GuRtfgRPJMvlfoWp9Aqjwk0pm8hd7h0i4ctjKCUKMTbMRS3X+vk68SHHzIs3ZwXc 64eJoed19PFgcw== X-ME-Sender: X-Sasl-enc: RA0K6m6UzEn4jWjvULC8ASgsluzUs0zHmDHdkZ4c1+Tj 1507156974 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 2F8367FA80; Wed, 4 Oct 2017 18:42:54 -0400 (EDT) From: Thomas Monjalon To: Ferruh Yigit , Kirill Rybalchenko Cc: dev@dpdk.org, andrey.chilikin@intel.com, beilei.xing@intel.com, jingjing.wu@intel.com Date: Thu, 05 Oct 2017 00:42:53 +0200 Message-ID: <7117136.lgPSGqLcVY@xps> In-Reply-To: References: <1503588634-85735-1-git-send-email-kirill.rybalchenko@intel.com> <2274280.QUHihWPneZ@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 0/2] ethdev: add support for raw flow type for flow director 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: Wed, 04 Oct 2017 22:42:55 -0000 04/10/2017 21:47, Ferruh Yigit: > On 10/4/2017 6:56 PM, Thomas Monjalon wrote: > > 04/10/2017 19:44, Ferruh Yigit: > >> On 10/4/2017 5:57 PM, Thomas Monjalon wrote: > >>> 03/10/2017 21:02, Ferruh Yigit: > >>>> On 9/20/2017 9:42 AM, Kirill Rybalchenko wrote: > >>>>> For complex packets use raw flow type with pre-constructed packet buffer > >>>>> instead of creating a packet internally in PMD. > >>> > >>> Sorry for not catching this series before. > >>> > >>> As it has been said several times on this mailing list, > >>> the flow director API is deprecated. > >>> I think everybody here knows that it is going to be replaced > >>> by rte_flow. > >>> > >>> That's why it does not make sense to extend flow director. > >>> We are not going to update PMDs to support a new type > >>> of legacy flow director. > >>> Please focus your efforts on rte_flow. > >> > >> As far as I can see this is not to to extend flow director. But driver > >> uses this struct and adding a new feature into driver requires update in > >> this struct. > >> > >> I guess idea was for new filter functionalities PMD should use rte_flow, > >> that is the new shiny method we have, I see the point here. But I don't > >> see the point of making these structs under use completely immutable. > > > > I don't know what is RTE_ETH_FLOW_RAW. > > Let's start by explaining it, how it is used by users, > > and why this struct is needed. > > Let me answer as much as I get from patches, if something is missing or > wrong Kirill needs to correct it. > > Driver (i40e) works with static pre-defined flow and pctypes. But new > feature DDP lets loading custom profiles and work with custom and > perhaps not yet defined flow and pctypes. So there are a few other > patches to make driver more dynamic. > > For this case I40E_VALID_FLOW() fails with custom flow types, and > RTE_ETH_FLOW_RAW used as kind of (void *) to be able to work with new > dynamic types. So the application could use a new flow type? If an application has to be modified for this, it can use rte_flow. Again, no new feature in legacy flow director.