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 2DB6CA0C47; Tue, 5 Oct 2021 13:11:52 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C53444132B; Tue, 5 Oct 2021 13:11:51 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 5EED441324 for ; Tue, 5 Oct 2021 13:11:51 +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 A56207F4FD; Tue, 5 Oct 2021 14:11:49 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru A56207F4FD DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1633432309; bh=Qln01A83FtS1yptwHImVBdHN9mOJ3s6DgdqhmQEBSOw=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=pxvv/odTco1JZPlGyzvvOo0+LZeVDOd7kR0P7S49AYRK50MlzvgSEbYMoCDMViF8D 15z7MAmi9qE1V9Rs8o3u6v9VK2QvIhTCMZQ52NQjVNP7K+ZFmeaTBUH4acwY1zmXSy VicGGPGa8jbmjzT3TTm1EnEZZ2SmxZqdGwVgBdX8= To: Ori Kam , Ivan Malov , NBU-Contact-Thomas Monjalon Cc: Andy Moreton , Ray Kinsella , "dev@dpdk.org" , Jerin Jacob , Wisam Monther , Xiaoyun Li , Ferruh Yigit References: <20210902142359.28138-1-ivan.malov@oktetlabs.ru> <06d5d165-a9e0-ecc6-74b5-20a77a88e301@oktetlabs.ru> <437bda42-b20d-9093-30a5-4a75be50c085@oktetlabs.ru> <7a68c7cf-2706-a637-c280-f485a0d24f0b@oktetlabs.ru> <254528d7-6534-0fb6-518f-4467fb09bd17@oktetlabs.ru> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <97fdd7cb-a8bf-65b6-30fd-6c1ca8c4af9e@oktetlabs.ru> Date: Tue, 5 Oct 2021 14:11:49 +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: 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" Hi Ori, On 10/5/21 1:10 PM, Ori Kam wrote: > Hi Andrew, > >> -----Original Message----- >> From: Andrew Rybchenko >> Sent: Tuesday, October 5, 2021 1:02 PM >> Subject: Re: [PATCH v3 1/5] ethdev: add API to negotiate delivery of Rx meta >> data >> >> Hi Ori, >> >> On 10/5/21 12:41 PM, Ori Kam wrote: >>> Hi Andrew, >>> >>>> -----Original Message----- >>>> From: Andrew Rybchenko >>>> Sent: Tuesday, October 5, 2021 11:39 AM >>>> Subject: Re: [PATCH v3 1/5] ethdev: add API to negotiate delivery of >>>> Rx meta data >>>> >>>> Hi Ori, >>>> >>>> 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. Could you take a look at v4 sent by Ivan yesterday and summarize current status of the review. Which points are still unclear and must be improved? What is desirable to improve from your point of view? Andrew.