From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 5BF72A0C45; Wed, 6 Oct 2021 10:30:21 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2EF0C413D0; Wed, 6 Oct 2021 10:30:21 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by mails.dpdk.org (Postfix) with ESMTP id 8A6DA41104 for ; Wed, 6 Oct 2021 10:30:20 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id DA4785C06EC; Wed, 6 Oct 2021 04:30:18 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 06 Oct 2021 04:30:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= peZH4aSYo4bXJAvQhhE7RzUgLNBYlg77lk70zHQWoJ8=; b=NfFkE9lINStJTA6J q15DdABJ1UxDyZjEe5Q8/Cvq3MQj6p3HWVR+G5cNBYJo4CvlMy17Q+T/xdoIdHEx IOPemgzAuQ9TKvvUZyfxohk3MnDiTeoqn9feGk40+sVP0S5DfNhVIt0Xc3lx3WGe 4XKX8mpTAxsl5kQBnae7NU0gmlOQNs75jS1j556cW5CupGKy6oDxEOYVA48sgI3Q 9kfhlzvVTdCLHWwnWKRTZJdJFOCDDWv0oZCUegBcTp10hbTUEdhjgjjpm3EWf5Jz mAiTu9Cl+2B9W+xgPBcwjxKa6MTqVocm2B2u5nd89LOPixsKPL2Ghikf9BY2HCvU 17HuPA== 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=peZH4aSYo4bXJAvQhhE7RzUgLNBYlg77lk70zHQWo J8=; b=KHkcAmB/0/iR5kt3qC3PQQivxJMytS+tQqc+yulkBYU5IGdk9PPoQ4m0t WXu+3aTxo135V/pLfJ0ONP9pDRe5/bgX9e4Ss3fCTnN7mvxv5wvnBa4T/nz0vnHK 2AUZ8NM9GT9rwF2BbGEgfkSFt+ovz7kEB3eSmkZ/AyMqa+/GGcQUymSjY8C9xEIT /LAIDJND+Qn/4sVCvDoGAOJ+/m8KGkWBa/MI9092vs4vCyp55dAhYuCZNrQ2yBkR GmKJK9/i/bQGkrkvRj5D8VDyI/y7m0Ddco4h80XiagBW0fZ95GyeGXOelUM87h8b X7/2yxHDb0Y+XI5rP13GCrVk3a7pw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudeliedgtddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 6 Oct 2021 04:30:15 -0400 (EDT) From: Thomas Monjalon To: Ori Kam , Andrew Rybchenko Cc: Ivan Malov , Andy Moreton , Ray Kinsella , "dev@dpdk.org" , Jerin Jacob , Wisam Monther , Xiaoyun Li , Ferruh Yigit Date: Wed, 06 Oct 2021 10:30:12 +0200 Message-ID: <2306193.isUc8XIZvh@thomas> In-Reply-To: <97fdd7cb-a8bf-65b6-30fd-6c1ca8c4af9e@oktetlabs.ru> References: <20210902142359.28138-1-ivan.malov@oktetlabs.ru> <97fdd7cb-a8bf-65b6-30fd-6c1ca8c4af9e@oktetlabs.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3 1/5] ethdev: add API to negotiate delivery of Rx meta data X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 05/10/2021 13:11, Andrew Rybchenko: > On 10/5/21 1:10 PM, Ori Kam wrote: > > From: Andrew Rybchenko > >> On 10/5/21 12:41 PM, Ori Kam wrote: > >>> From: Andrew Rybchenko > >>>> On 10/5/21 11:17 AM, Ori Kam wrote: > >>>>> One more thing, I think this flag should be added now since you need > >>>>> it, I think you should report that you don't support it. > >>>>> since just like we talked there is no real difference between metadata and > >> MARK. > >>>>> What do you think? > >>>> > >>>> It sounds like a trick :) Negative support is *not* a support in > >>>> fact. DPDK policy requires support of a feature in a PMD and in-tree > >>>> application. Of course, it is not a problem to add meta. It is really > >>>> easy to do. I just don't want to add it in > >>>> v5 to be deleted in v6 because of my above concerns. > >>>> > >>> This was not a trick. I understand what you are saying. > >>> if we say that metadata is the same as mark, (I think we all agree on > >>> it) and that application need to notify pmd about such operations, I > >>> assume it will try to see how to request the metadata. > >> > >> Frankly speaking I feel sick when I think about META and MARK together. Do > >> we really need both in DPDK? > >> > > I realy don't want you the be sick, > > The resoun that we need both of them is that 32 in Nvidia it is only 24 bits of mark is not > > enough, so there is a need for more bits. > > I think that in the end we will go to something much more generic that the application > > will just say how many bits it wants to get and this what he will get. > > for example the application may say it needs 128 bits and it will register this size to the mbuf > > or give in the mbuf pointer two where those values should be set. > > In any case as you can see we have already to many changes in rte_flow in this release and the > > next one, but I'm planning to push this feature in the future > > what do you think of such a feature? > > I agree that there are really many changes in flow API which > are on review in the release cycle. > I hope the above idea will allow to merge MARK and META. I agree we should merge mark and meta in a common dynamic mbuf field. What do we need in mark which is not in meta? I think dynamic mbuf field of meta is the way to go but I prefer the name "mark" :)