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 76C37A0C43; Thu, 30 Sep 2021 21:30:37 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0929240DDA; Thu, 30 Sep 2021 21:30:37 +0200 (CEST) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id 388E84067E for ; Thu, 30 Sep 2021 21:30:35 +0200 (CEST) Received: from [100.65.5.102] (unknown [5.144.120.126]) (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 B03B87F6C0; Thu, 30 Sep 2021 22:30:34 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru B03B87F6C0 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1633030234; bh=7Fjb4Wn+XwNNOUp1I4iq/BVOr/ED32rGy2wGm1NU1ns=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=ElXSAH7wuJf/slfdteu6O6IFhxb682qyiPJVW9zswsVws5zeG9oY2USF5ea+uQw90 LSDbrArgoR/zp/xOdvd8Ai78IQFXrzn8ljlVX+q8WoAFIXO0WwqGbqJDPS6U0PioLZ ZGpUk1rbQXBlJFizuN7e0K/xWvCrl/QJoi83ky7o= To: Thomas Monjalon Cc: dev@dpdk.org, Andy Moreton , orika@nvidia.com, andrew.rybchenko@oktetlabs.ru, ferruh.yigit@intel.com References: <20210902142359.28138-1-ivan.malov@oktetlabs.ru> <20210923112012.14595-1-ivan.malov@oktetlabs.ru> <3799988.YkIh4iXpRk@thomas> From: Ivan Malov Message-ID: <8e727e12-6655-43b9-9af3-bcc5b882508d@oktetlabs.ru> Date: Thu, 30 Sep 2021 22:30:23 +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: <3799988.YkIh4iXpRk@thomas> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v3 0/5] A means 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 Thomas, On 30/09/2021 19:18, Thomas Monjalon wrote: > 23/09/2021 13:20, Ivan Malov: >> In 2019, commit [1] announced changes in DEV_RX_OFFLOAD namespace >> intending to add new flags, RSS_HASH and FLOW_MARK. Since then, >> only the former has been added. The problem hasn't been solved. >> Applications still assume that no efforts are needed to enable >> flow mark and similar meta data delivery. >> >> The team behind net/sfc driver has to take over the efforts since >> the problem has started impacting us. Riverhead, a cutting edge >> Xilinx smart NIC family, has two Rx prefix types. Rx meta data >> is available only from long Rx prefix. Switching between the >> prefix formats can't happen in started state. Hence, we run >> into the same problem which [1] was aiming to solve. > > Sorry I don't understand what is Rx prefix? A small chunk of per-packet metadata in Rx packet buffer preceding the actual packet data. In terms of mbuf, this could be something lying before m->data_off. >> Rx meta data (mark, flag, tunnel ID) delivery is not an offload >> on its own since the corresponding flows must be active to set >> the data in the first place. Hence, adding offload flags >> similar to RSS_HASH is not a good idea. > > What means "active" here? Active = inserted and functional. What this paragraph is trying to say is that when you enable, say, RSS_HASH, that implies both computation of the hash and the driver's ability to extract in from packets ("delivery"). But when it comes to MARK, it's just "delivery". No "offload" here: the NIC won't set any mark in packets unless you create a flow rule to make it do so. That's the gist of it. >> Patch [1/5] of this series adds a generic API to let applications >> negotiate delivery of Rx meta data during initialisation period. >> This way, an application knows right from the start which parts >> of Rx meta data won't be delivered. Hence, no necessity to try >> inserting flows requesting such data and handle the failures. > > Sorry I don't understand the problem you want to solve. > And sorry for not noticing earlier. No worries. *Some* PMDs do not enable delivery of, say, Rx mark with the packets by default (for performance reasons). If the application tries to insert a flow with action MARK, the PMD may not be able to enable delivery of Rx mark without the need to re-start Rx sub-system. And that's fraught with traffic disruption and similar bad consequences. In order to address it, we need to let the application express its interest in receiving mark with packets as early as possible. This way, the PMD can enable Rx mark delivery in advance. And, as an additional benefit, the application can learn *from the very beginning* whether it will be possible to use the feature or not. If this API tells the application that no mark delivery will be enabled, then the application can just skip many unnecessary attempts to insert wittingly unsupported flows during runtime. -- Ivan M