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 0D696A0C43; Thu, 30 Sep 2021 18:18:13 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C1B49410E5; Thu, 30 Sep 2021 18:18:12 +0200 (CEST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mails.dpdk.org (Postfix) with ESMTP id A25FC40DDA for ; Thu, 30 Sep 2021 18:18:11 +0200 (CEST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 1AC9A5C0197; Thu, 30 Sep 2021 12:18:11 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 30 Sep 2021 12:18:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= uZwlL2FpxVYATlKe/gIPDHpsbTm0TtOwV92uqZtPPfY=; b=eN9i2e0xlaVvPuZY UBVSyxceUP741vvnjUwqrWWUzrtiTch0acL4ceIaisKkV0Ae1GSct/yMgFd7+ItZ R4Uvkug/qhqwrrw5pgUC5aos8I/4h8c+y/NnNdPPJmiWZzBp9+L5WUh/P1p6Z1gu 5dnps9I2yhDqWAyJWmbLKMVSXws3fzpnYVtK5fBL0/WGR7wwf9Ew87MpuAKuEL3H tMVbsDvAlWRgrn7zQZXbqX2+LHCjjI70tH7ssv9WEX2V8y0oZA3bJz3fRIfRNePQ WK//sX9pdokYAJbEwAbmIZVJcmMvN52DxgKUOTxPD7DUw7qBmyud4XdV2hHthUGs B7gpRQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=uZwlL2FpxVYATlKe/gIPDHpsbTm0TtOwV92uqZtPP fY=; b=r3WEVybjCsWs7jftlMezhWpUCpBuvmL7+HyzqgHeOmsNMKXz+zoReZi+W dIjKk1jtPrQImBppneo9PBBOX1yUXVEi2ilQHZUixfZr0uxYoJLLZPNY76te+dsQ 0ueX6dQJ4OLcbRRuJtuRawSPvObRf0UPBCmoZDyKgG/apElPBajxEKAM4IUJj+yR E08EB55tDs8rjOkrOBoyGfHDH/iEJc3uby8miqi8SXjnkJmJxvRzb1noKnAa4eQw iYitcZB9SpyS1W+M6FWiYGvBHsJ8wRUuRC7Oh0/HCL3zI5Z6zpwmHxdMZVfGEXaD VFHOGGi05tX6QNUuzorN2vQfSxh3Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudekgedgleeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 30 Sep 2021 12:18:10 -0400 (EDT) From: Thomas Monjalon To: Ivan Malov Cc: dev@dpdk.org, Andy Moreton , orika@nvidia.com, andrew.rybchenko@oktetlabs.ru, ferruh.yigit@intel.com Date: Thu, 30 Sep 2021 18:18:09 +0200 Message-ID: <3799988.YkIh4iXpRk@thomas> In-Reply-To: <20210923112012.14595-1-ivan.malov@oktetlabs.ru> References: <20210902142359.28138-1-ivan.malov@oktetlabs.ru> <20210923112012.14595-1-ivan.malov@oktetlabs.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 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? > 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? > 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.