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 7D0D0A0C4D; Mon, 4 Oct 2021 15:53:07 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 084BD41266; Mon, 4 Oct 2021 15:53:07 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id B85B041255 for ; Mon, 4 Oct 2021 15:53:05 +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 2F5EB7F508; Mon, 4 Oct 2021 16:53:05 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 2F5EB7F508 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1633355585; bh=QLx9OT636QbkbB/QMQKBZvIlwA/NXY3A8UR435INZ/o=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=Iv2bn0zS9iTLLhyXPHzBEqazzzG8qRSh+hPvhshNpJPgE/CHP+14rGZIXfVpmeHXZ DWkYpAvwZ9h2q/a4187wA+OdDHzxz8msx3W/F+kRb7QtPuF8uGXLvglAMOWxypjSlQ nl3EQO+jym1hE0u3Xeq07rFttyAvUZ/dpJZDpuxs= To: Ivan Malov , Ori Kam , "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-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> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: <7a68c7cf-2706-a637-c280-f485a0d24f0b@oktetlabs.ru> Date: Mon, 4 Oct 2021 16:53:05 +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: <437bda42-b20d-9093-30a5-4a75be50c085@oktetlabs.ru> 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/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).