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 2428AA0C47; Tue, 5 Oct 2021 10:38:36 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 914CD412EB; Tue, 5 Oct 2021 10:38:35 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id DF822412DE for ; Tue, 5 Oct 2021 10:38:33 +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 432EC7F609; Tue, 5 Oct 2021 11:38:33 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 432EC7F609 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1633423113; bh=4QNi+wBdas9Mq1B0K+DEiwZhFxvWBzVI5KLgQo/4w3Y=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=RvTw5a0lOsQUABMLfn5Mf5hPdnKCJPMxbv6X95Oe/XhbsB72EnkLIQqB1x98bdX3I Evr2F1PvMRahL+0rtDjWYU7BmrK6YwSrqpem2DZvC/pbW0jZ1fBszZjnuJrBsq4SCj syvIVZDzRjSuBWpwkV7OX4WNOoFb4GDxssK8cHtM= 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> <6e9703ae-9fe0-2656-c08f-da95e44bcdeb@oktetlabs.ru> <06d5d165-a9e0-ecc6-74b5-20a77a88e301@oktetlabs.ru> <437bda42-b20d-9093-30a5-4a75be50c085@oktetlabs.ru> <7a68c7cf-2706-a637-c280-f485a0d24f0b@oktetlabs.ru> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <254528d7-6534-0fb6-518f-4467fb09bd17@oktetlabs.ru> Date: Tue, 5 Oct 2021 11:38:33 +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: 8bit 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 11:17 AM, Ori Kam wrote: > Hi Andrew, > >> -----Original Message----- >> From: Andrew Rybchenko >> Sent: Tuesday, October 5, 2021 10:27 AM >> Subject: Re: [PATCH v3 1/5] ethdev: add API to negotiate delivery of Rx meta >> data >> >> On 10/5/21 9:30 AM, Ori Kam wrote: >>> Hi Andrew, >>> >>>> -----Original Message----- >>>> From: Andrew Rybchenko >>>> Sent: Monday, October 4, 2021 4:53 PM >>>> Subject: Re: [PATCH v3 1/5] ethdev: add API to negotiate delivery of >>>> Rx meta data >>>> >>>> On 10/4/21 2:39 PM, Ivan Malov wrote: >>>>> On 04/10/2021 09:56, Ori Kam wrote: >>>>>>> On 04/10/2021 00:04, Ori Kam wrote: >>>>>>>> I understand that you are only talking about enabling the action, >>>>>>>> meaning to let the PMD know that at some point there will be a >>>>>>>> rule that will use the mark action for example. >>>>>>>> Is my understanding correct? >>>>>>> Not really. The causal relationships are as follows. The >>>>>>> application comes to realise that it will need to use, say, action >>>>>>> MARK in flows. >>>>>>> This, in turn, means that, in order to be able to actually see the >>>>>>> mark in received packets, the application needs to ensure that a) >>>>>>> the NIC will be able to deliver the mark to the PMD and b) that >>>>>>> the PMD will be able to deliver the mark to the application. In >>>>>>> particular, in the case of Rx mark, >>>>>>> (b) doesn't >>>>>>> need to be negotiated = field "mark" is anyway provisioned in the >>>>>>> mbuf structure, so no need to enable it. But (a) needs to be negotiated. >>>>>>> Hence this >>>>>>> API. >>>>>>> >>>>>> Please see my above comment I think we both agree. >>>>> Agree to have the 4-th flag in the new API to cover this "custom / >>>>> raw metdata" delivery? Personally, I tend to agree, but maybe Andrew >>>>> can express his opinion, too. >>>> Of course, it could be added, but we're not going to support it in >>>> net/sfc. So, I think the flag should be added when a PMD will going to >> support it (e.g. >>>> net/mlx5). >>> I think it should be added now, and more I think that this patch >>> should add the missing function to all PMDs 😊 >> >> Sorry, but I disagree. Could you point out to DPDK documentation where it is >> written? Should all new API be supported in all PMDs by the API contributor? >> > This changes existing PMD beavior, until now there was no need to register the MARK > now you require it, it is just like change the shared counter you needed to fix different drivers. > This is not critical to me like I said in other thread as long is it is clear that if PMD doesn't support > the new function it doesn't mean the the PMD has issue with the request. I see your point. Hopefully the function description in v4 is clear that it is not the case. If callback is not supported by a driver, application should try to use all required metadata. So, there is no breakage in accordance with defined API contract. Many thanks for your review notes. The review really makes the API clearer and better documented. > 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. @Thomas, what do you think? Andrew.