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 76083A0C4C; Tue, 5 Oct 2021 15:17:27 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3AECF4134A; Tue, 5 Oct 2021 15:17:27 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 811A0412D0 for ; Tue, 5 Oct 2021 15:17:26 +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 F18AE7F504; Tue, 5 Oct 2021 16:17:25 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru F18AE7F504 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1633439846; bh=UskCrCfmWYaEuVsTOQOPAokShtXo7VQKZLpyp7stZrU=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=g2/WuyAQVKW2inZOH/Znx1tFZJ8RcUMBrJ1b6J5GvuyLI0eM9bEuPvvjNVtoNzp0h gzKD8R1/vJKgllpk7PtsC9lV23n4NUJXTbKfOLLMuSQjw1xVcuHbXSOF2ZwObS0gju 3eeMFL7bfC4h3wCH4KY6/3miftMY5eSUg4DDlamA= To: Ivan Malov , Ori Kam , "dev@dpdk.org" Cc: Ray Kinsella , Jerin Jacob , NBU-Contact-Thomas Monjalon , Ajit Khaparde , Andy Moreton , Wisam Monther , Xiaoyun Li , Ferruh Yigit References: <20210923112012.14595-1-ivan.malov@oktetlabs.ru> <20211004235007.12293-1-ivan.malov@oktetlabs.ru> <20211004235007.12293-2-ivan.malov@oktetlabs.ru> From: Andrew Rybchenko Organization: OKTET Labs Message-ID: Date: Tue, 5 Oct 2021 16:17:25 +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 v4 1/5] ethdev: negotiate delivery of packet metadata from HW to PMD 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 3:50 PM, Ivan Malov wrote: > Hi Ori, > > On 05/10/2021 15:03, Ori Kam wrote: >> Hi Ivan, >> >> Just a nit below. >> >>> -----Original Message----- >>> From: Ivan Malov >>> Sent: Tuesday, October 5, 2021 2:50 AM >>> Subject: [PATCH v4 1/5] ethdev: negotiate delivery of packet metadata >>> from >>> HW to PMD >>> >>> Provide an API to let the application control the NIC's ability to >>> deliver specific >>> kinds of per-packet metadata to the PMD. >>> >>> Checks for the NIC's ability to set these kinds of metadata in the >>> first place >>> (support for the flow actions) belong in flow API responsibility >>> domain (flow >>> validate mechanism). >>> This topic is out of scope of the new API in question. >>> >>> The PMD's ability to deliver received metadata to the user by virtue >>> of mbuf >>> fields should be covered by mbuf library. >>> It is also out of scope of the new API in question. >>> >> >> +1 very clear. >> >>> Signed-off-by: Ivan Malov >>> Reviewed-by: Andrew Rybchenko >>> Reviewed-by: Andy Moreton >>> Acked-by: Ray Kinsella >>> Acked-by: Jerin Jacob >>> --- >> >> [Snip] >> >>> --- a/lib/ethdev/rte_ethdev.h >>> +++ b/lib/ethdev/rte_ethdev.h >>> @@ -4902,6 +4902,59 @@ __rte_experimental  int >>> rte_eth_representor_info_get(uint16_t port_id, >>>                    struct rte_eth_representor_info *info); >>> >>> +/** The NIC is able to deliver flag (if set) with packets to the PMD. >>> +*/ #define RTE_ETH_RX_METADATA_USER_FLAG (UINT64_C(1) << 0) >>> + >>> +/** The NIC is able to deliver mark ID with packets to the PMD. */ >>> +#define RTE_ETH_RX_METADATA_USER_MARK (UINT64_C(1) << 1) >>> + >>> +/** The NIC is able to deliver tunnel ID with packets to the PMD. */ >>> +#define RTE_ETH_RX_METADATA_TUNNEL_ID (UINT64_C(1) << 2) >>> + >>> +/** >>> + * @warning >>> + * @b EXPERIMENTAL: this API may change without prior notice >>> + * >>> + * Negotiate the NIC's ability to deliver specific kinds of metadata >>> to the PMD. >>> + * >>> + * Invoke this API before the first rte_eth_dev_configure() invocation >>> + * to let the PMD make preparations that are inconvenient to do later. >>> + * >>> + * The negotiation process is as follows: >>> + * >>> + * - the application requests features intending to use at least some >>> +of them; >>> + * - the PMD responds with the guaranteed subset of the requested >>> +feature set; >>> + * - the application can retry negotiation with another set of >>> +features; >>> + * - the application can pass zero to clear the negotiation result; >>> + * - the last negotiated result takes effect upon the ethdev start. >> >> Not upon ethdev configure? > > Well, technically, doing "configure()" just closes the negotiation > window. I guess, "to take effect" is "to be activated", and activation > of Rx features typically happens on Rx subsystem start. Yes, i.e. ethdev port start from application point of view > I know it might seem a bit inconsistent, but in any case the API > contract says clearly that invocations of "metadata_negotiate()" should > be done before "configure()". > > Andrew? Yes, the reason to define order is to simplify implementation. When configure is invoked, PMD know that Rx metadata are negotiated and it should treat all other bits of the configuration with respect to Rx metadata configuration, of course, if applicable. So, I think the question is right and correct description should say: ... upon the ethdev configure and start. Andrew.