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 D0ADFA054F; Tue, 2 Mar 2021 10:42:18 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 4E0154014E; Tue, 2 Mar 2021 10:42:18 +0100 (CET) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) by mails.dpdk.org (Postfix) with ESMTP id 4B78E40142 for ; Tue, 2 Mar 2021 10:42:17 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 3FBC3580554; Tue, 2 Mar 2021 04:42:14 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 02 Mar 2021 04:42:14 -0500 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=fm3; bh= Ps5AMbl8dBEudbeLB5TnnnLfg8iEYzZaWFtfB2B25+8=; b=iwmwjp5i6YR9d0GQ c4nez2pXimOKzauNvYQMvPotFJFegoCCsVSK78H2Hs2CCStS2j3/EJRhbwc2cGKR MlQzBEybDly/oCwvjCY3l3akEwGgxj4pV81shZctHUxBCbQ3pmZuMr8tf+k1OHzu 8wa+AvhVR07/asE52Dm1goxTFdxQLUuAW4UkiHeWM7NNqDX/tpigGGtAWwgIyYzp vZ2vlZwj7GaUVGuADae9fydeyXWyk+l+L70Z4LhLKYIZk8PT5hPYKyKXCW04nFt6 BpBYAtkxM9hftAkaMF6KEh1Qoo6yesXAcFFRHkQDXtYy1GO3e3QQVpaPsjfNgiUE oSTzVw== 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=fm2; bh=Ps5AMbl8dBEudbeLB5TnnnLfg8iEYzZaWFtfB2B25 +8=; b=aU9piktAXYvV9JsyU0yW4nbW380Mxm8VXZ0jLsoRNAETvNYOfyNalzx5Z vdU8D/5lXIujskFirgI59D3vDye1z3wR8aXFLhgQxDYo/x5bDCCG38gPkR3J7PU1 3bbMlPfFxQfSKhEzDcCWr04u6f8n2u6NDJY0wzG1NZHvJAGxO1Xj47qiPkFXVejr dAP6Imh4ScuSOikfFAEf5bf1jgwQmKs+21PRAeXwqGmGcFKDPtmM9+pGX7f8lqRe /aeXz2Jm3e1TeX7r6iWxKHcDags7zAK/VQVGfOtlnhC3obFATnEZDSg2rP5N0Edi u+eEajU1QkZIvVE18Ilk/HF4GX5MQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddttddgtdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id A39F2240066; Tue, 2 Mar 2021 04:42:11 -0500 (EST) From: Thomas Monjalon To: Gregory Etelson , Ivan Malov Cc: dev@dpdk.org, matan@nvidia.com, rasland@nvidia.com, elibr@nvidia.com, ozsh@nvidia.com, asafp@nvidia.com, Eli Britstein , Ori Kam , Viacheslav Ovsiienko , Ray Kinsella , Neil Horman , Ferruh Yigit , Andrew Rybchenko Date: Tue, 02 Mar 2021 10:42:09 +0100 Message-ID: <7994628.OkqbbpkKdt@thomas> In-Reply-To: <5dd2ef9d-dc87-3a0e-8bcd-c093f717222d@oktetlabs.ru> References: <20200625160348.26220-1-getelson@mellanox.com> <20201016125108.22997-3-getelson@nvidia.com> <5dd2ef9d-dc87-3a0e-8bcd-c093f717222d@oktetlabs.ru> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v8 2/3] ethdev: tunnel offload model 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" 02/03/2021 10:22, Ivan Malov: > Hi Gregory, Eli, > > On 16/10/2020 15:51, Gregory Etelson wrote: > > Applications wishing to offload tunneled traffic are required to use > > the rte_flow primitives, such as group, meta, mark, tag, and others to > > model their high-level objects. The hardware model design for > > As far as I understand, the model is an abstraction of sorts, and the > quoted lines provide examples of primitives which applications would > have to use if the model did not exist. > > Looking at the implementation, I don't quite discern any means to let > the application query PMD-specific values of "rte_flow_attr". In > example, the PMD may need to enforce "transfer=1" both for the "tunnel > set" rule and for "tunnel match" one. What if "group" and "priority" > values also need to be implicitly controlled by the PMD for the tunnel > offload rules? > > Have you considered adding an abstraction for "rte_flow_attr" in terms > of this model? > > > The first VXLAN packet that arrives matches the rule in group 0 and > > jumps to group 3. In group 3 the packet will miss since there is no > > This example considers jumping from group 0 to group 3. First of all, > it's unclear whether this model intentionally lets the application > choose group values freely (see my question above) or simply lacks an > interface to let the application use values enforced by the PMD (if > any). Secondly, given the fact that existing description of > "rte_flow_attr" does not shed any light on how groups are ordered by > default, when no JUMPs are configured (it only explains how priority > levels are ordered within the given group but not how groups are > ordered), it's unclear whether the model intentionally permits the > application to jump between arbitrary groups (in example, from 0 to 3) > and not necessarily between, say, 0 to 1. More to that, it's unclear > whether the model lets the application jump from, say, group 0 to the > very same group, 0 ("recirculation") or not. Or is the "recirculation" > is in fact the main scenario in the model? Could you please elaborate on > the model's expectations of groups? > > Thank you. Given the questions, I think the discussion should be concluded (when done) with a patch updating the API description. Thanks for the questions and clarifications to come :)