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 DA3C9A0C41; Tue, 5 Oct 2021 09:27:06 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 682A941262; Tue, 5 Oct 2021 09:27:06 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id E4B914124E for ; Tue, 5 Oct 2021 09:27:04 +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 4ED787F4FD; Tue, 5 Oct 2021 10:27:04 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 4ED787F4FD DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1633418824; bh=hxoeXh1B46hyUgAsMa/Q+TROnLIynXbxx73KrupYbBo=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=XqkAGscOcKMwcTHfqJU2ujcJTEV+B3dfq2SiLLaCGWtYFUmJ8NAFA9H0Jnpru+S9n WCz16ObV8Wl0bC7KRgADpCQQwwteupCKBTOFb+8Gy6A8Uirk4Th9CGvL+ucqkfnMXs lkRvTjh/E8KMUBJOf9bwVnbg5S2wdW3O5QrOJiBA= To: Ori Kam , Ivan Malov , "dev@dpdk.org" Cc: Andy Moreton , Ray Kinsella , Jerin Jacob , Wisam Monther , Xiaoyun Li , NBU-Contact-Thomas Monjalon , Ferruh Yigit References: <20210902142359.28138-1-ivan.malov@oktetlabs.ru> <20210923112012.14595-2-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: Date: Tue, 5 Oct 2021 10:27:04 +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-Transfer-Encoding: 8bit Content-Language: en-US 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/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? Andrew.