From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v2 0/2] ethdev: add support for raw flow type for flow director Date: Thu, 05 Oct 2017 00:42:53 +0200 Message-ID: <7117136.lgPSGqLcVY@xps> References: <1503588634-85735-1-git-send-email-kirill.rybalchenko@intel.com> <2274280.QUHihWPneZ@xps> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org, andrey.chilikin@intel.com, beilei.xing@intel.com, jingjing.wu@intel.com To: Ferruh Yigit , Kirill Rybalchenko 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) In-Reply-To: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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.