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 08A8CA0C45; Wed, 6 Oct 2021 10:38:29 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 80D20410FA; Wed, 6 Oct 2021 10:38:29 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 13DEB40688 for ; Wed, 6 Oct 2021 10:38:28 +0200 (CEST) Received: from [192.168.38.17] (aros.oktetlabs.ru [192.168.38.17]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id 68D727F4C4; Wed, 6 Oct 2021 11:38:27 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 68D727F4C4 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1633509507; bh=HbzJcTqT2iNAwd4ZlEnwMzH9iRzRCaaMdQTXZ3Z52S4=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=JyG6Mq0TlF81FDQ/rQznyMjwIVQeuCIQ/mFetQMvVgJOY20A79uoUxzjjWBder4+Q 3ASQlggr3j4cGxfVMJ7GgTWkkKSN/2jcRX6mjahfdM8a9JiwqhSwMkGpkOnP5ceqG0 n0D3eQSzQztdWXp0lR8E7zU7tSGujWLEb8dzkxig= To: Thomas Monjalon , Ori Kam Cc: Ivan Malov , Andy Moreton , Ray Kinsella , "dev@dpdk.org" , Jerin Jacob , Wisam Monther , Xiaoyun Li , Ferruh Yigit References: <20210902142359.28138-1-ivan.malov@oktetlabs.ru> <97fdd7cb-a8bf-65b6-30fd-6c1ca8c4af9e@oktetlabs.ru> <2306193.isUc8XIZvh@thomas> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <88c6605c-c7b3-9d0e-75af-756486ac46e8@oktetlabs.ru> Date: Wed, 6 Oct 2021 11:38:27 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <2306193.isUc8XIZvh@thomas> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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" On 10/6/21 11:30 AM, Thomas Monjalon wrote: > 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" :) > +1 but I don't have answer to the question