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 9B51AA0C47; Tue, 5 Oct 2021 14:50:47 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5B8914134B; Tue, 5 Oct 2021 14:50:47 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 72BBD4134A for ; Tue, 5 Oct 2021 14:50:46 +0200 (CEST) Received: from [100.65.5.102] (unknown [5.144.121.98]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by shelob.oktetlabs.ru (Postfix) with ESMTPSA id DB7287F508; Tue, 5 Oct 2021 15:50:45 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru DB7287F508 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1633438246; bh=SRCiZl37flH29GYaQWd+AVIgw0nSFkD6EHJuqB5+7tg=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=FyjjSwxRV/QR0DqmL15dGhnSvmjX18NvEBWK8Ps69p/ECWBTlS8la4FbVhymB0YRz lsypqm0SQJ7GbPmuh/wdwej60WoBJdXMbBxzqFx4o1xTuAg/2NEdWrIwhzbWK3VGCS qCu2sz/gdYgJqBTTVvrni8D+OR8UhqxwxYxJzEro= To: Ori Kam , "dev@dpdk.org" Cc: Ray Kinsella , Jerin Jacob , NBU-Contact-Thomas Monjalon , Ajit Khaparde , Andrew Rybchenko , 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: Ivan Malov Message-ID: Date: Tue, 5 Oct 2021 15:50:34 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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" 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. 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? > >> + * >> + * @note >> + * The PMD is supposed to first consider enabling the requested feature set >> + * in its entirety. Only if it fails to do so, does it have the right to >> + * respond with a smaller set of the originally requested features. >> + * >> + * @note >> + * Return code (-ENOTSUP) does not necessarily mean that the requested >> + * features are unsupported. In this case, the application should just >> + * assume that these features can be used without prior negotiations. >> + * >> + * @param port_id >> + * Port (ethdev) identifier >> + * >> + * @param[inout] features >> + * Feature selection buffer >> + * >> + * @return >> + * - (-EBUSY) if the port can't handle this in its current state; >> + * - (-ENOTSUP) if the method itself is not supported by the PMD; >> + * - (-ENODEV) if *port_id* is invalid; >> + * - (-EINVAL) if *features* is NULL; >> + * - (-EIO) if the device is removed; >> + * - (0) on success >> + */ >> +__rte_experimental >> +int rte_eth_rx_metadata_negotiate(uint16_t port_id, uint64_t >> +*features); >> + >> #include >> >> /** >> diff --git a/lib/ethdev/rte_flow.h b/lib/ethdev/rte_flow.h index >> 7b1ed7f110..75656ff9f8 100644 >> --- a/lib/ethdev/rte_flow.h >> +++ b/lib/ethdev/rte_flow.h >> @@ -1904,6 +1904,10 @@ enum rte_flow_action_type { >> * PKT_RX_FDIR_ID mbuf flags. >> * >> * See struct rte_flow_action_mark. >> + * >> + * One should negotiate mark delivery from the NIC to the PMD. >> + * @see rte_eth_rx_metadata_negotiate() >> + * @see RTE_ETH_RX_METADATA_USER_MARK >> */ >> RTE_FLOW_ACTION_TYPE_MARK, >> >> @@ -1912,6 +1916,10 @@ enum rte_flow_action_type { >> * sets the PKT_RX_FDIR mbuf flag. >> * >> * No associated configuration structure. >> + * >> + * One should negotiate flag delivery from the NIC to the PMD. >> + * @see rte_eth_rx_metadata_negotiate() >> + * @see RTE_ETH_RX_METADATA_USER_FLAG >> */ >> RTE_FLOW_ACTION_TYPE_FLAG, >> >> @@ -4223,6 +4231,10 @@ rte_flow_tunnel_match(uint16_t port_id, >> /** >> * Populate the current packet processing state, if exists, for the given mbuf. >> * >> + * One should negotiate tunnel metadata delivery from the NIC to the HW. >> + * @see rte_eth_rx_metadata_negotiate() >> + * @see RTE_ETH_RX_METADATA_TUNNEL_ID >> + * >> * @param port_id >> * Port identifier of Ethernet device. >> * @param[in] m >> diff --git a/lib/ethdev/version.map b/lib/ethdev/version.map index >> 904bce6ea1..2e638c680e 100644 >> --- a/lib/ethdev/version.map >> +++ b/lib/ethdev/version.map >> @@ -247,6 +247,9 @@ EXPERIMENTAL { >> rte_mtr_meter_policy_delete; >> rte_mtr_meter_policy_update; >> rte_mtr_meter_policy_validate; >> + >> + # added in 21.11 >> + rte_eth_rx_metadata_negotiate; >> }; >> >> INTERNAL { >> -- >> 2.20.1 > Best, > Ori > -- Ivan M