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 4EA471B6CE for <dev@dpdk.org>; Wed, 4 Oct 2017 19:56:24 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id AC99620D87; Wed, 4 Oct 2017 13:56:23 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 04 Oct 2017 13:56:23 -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=Lwrh20c9gJpJqfx paoJo+iEbxV2IXSe5K+t91fVHI3A=; b=BVQB5YnWjFxAnZ1qM9iiaUjxl7IDCW3 tzQYolbO0RtE30s8ZFTt9BzKW2604JLbhXOJeZoqUMAVXDmKMoWfkTr/jLNCEPNU SRY5Vw/Gt16rIb+dV6UrKBCikKcihaUf88V2jt06eYOYRc9QiMUZq41IHEDBRSeb 5bxDA/uJUrbc= 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=Lwrh20c9gJpJqfxpaoJo+iEbxV2IXSe5K+t91fVHI3A=; b=SYLheJeP 7RTuI5H4BKXQt8sDEHnxB6VXWc+sZw7idEGlef/tAlB2HhYcZpBZ7HIOhqNAJi17 o36WzgcMkgg2TTg606YFCX/H4hmO0qYRUzS88DctM7zwNS73tLlkcyTp90pv+A/0 mhvp0ZnKpYd1zXOj7Y6C+NyEcfX5BukdxxIXngMoK+i2RpLuKKowlks6F+kOuhKe jsulR+yoPF0DzBq8FT8Yi/c8tHHyaPlUPLmnHxXv27NBNn+8zDBZOR/rSAVv64eW MNnaCq5OW8bPclUXoPcVrMf2KQGJUrARfZIuJU+7lUqz8MJov5qzwBorWM00SkMa vMwuH1u7Odwe3w== X-ME-Sender: <xms:xyDVWdG3fpc6MUID44leYlDBLxkVSL9MwD31ooFKMoZuYbNgJ7AGZg> X-Sasl-enc: gxOQOmbpaLnf2kwRqv992hU2bvVaxy0P8eWksRXP9gf8 1507139783 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 460C47E1D8; Wed, 4 Oct 2017 13:56:23 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: Kirill Rybalchenko <kirill.rybalchenko@intel.com> Cc: dev@dpdk.org, Ferruh Yigit <ferruh.yigit@intel.com>, andrey.chilikin@intel.com, beilei.xing@intel.com, jingjing.wu@intel.com Date: Wed, 04 Oct 2017 19:56:22 +0200 Message-ID: <2274280.QUHihWPneZ@xps> In-Reply-To: <e96e47fc-0ae3-84b0-930f-c0351c8b2094@intel.com> References: <1503588634-85735-1-git-send-email-kirill.rybalchenko@intel.com> <13345393.msxc2hlS7D@xps> <e96e47fc-0ae3-84b0-930f-c0351c8b2094@intel.com> 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 <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: Wed, 04 Oct 2017 17:56:24 -0000 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. Thanks