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 00461A055D; Wed, 3 Mar 2021 15:03:49 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8948240683; Wed, 3 Mar 2021 15:03:49 +0100 (CET) Received: from shelob.oktetlabs.ru (shelob.oktetlabs.ru [91.220.146.113]) by mails.dpdk.org (Postfix) with ESMTP id E04274067B for ; Wed, 3 Mar 2021 15:03:48 +0100 (CET) Received: from [192.168.45.100] (unknown [188.242.7.54]) (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 4A7617F521; Wed, 3 Mar 2021 17:03:48 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 shelob.oktetlabs.ru 4A7617F521 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=oktetlabs.ru; s=default; t=1614780228; bh=Tyyrp9bdpur0VAcqlCnFXMg9sEWoIPvcHOUu/B8F1VU=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=P3C1SPnlXUYYs8/QcrCz2aJDVae6SG8g+NRBVgOEV04XNwOEhE8vc1Fe+oWw1UJRK 86DYughIbK+u7J6JhbiHMiW5YAMSlqNlnYQQjM+AkJqGM/e3mIyKzD+95iTwLNjFO0 BaRmyzhPL+HHNuzrcE7wggb4e5qppbjofWiGcnlg= To: Thomas Monjalon , Gregory Etelson 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 References: <20200625160348.26220-1-getelson@mellanox.com> <20201016125108.22997-3-getelson@nvidia.com> <5dd2ef9d-dc87-3a0e-8bcd-c093f717222d@oktetlabs.ru> <7994628.OkqbbpkKdt@thomas> From: Ivan Malov Message-ID: <4a5ec329-bd91-e9d6-7578-be4e093bffa4@oktetlabs.ru> Date: Wed, 3 Mar 2021 17:03:46 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <7994628.OkqbbpkKdt@thomas> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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" Hi, Could someone please also clarify the meaning (from PMD standpoint and from application's standpoint) of the 64-bit field "tun_id" in "rte_flow_tunnel"? The current comment reads: "Tunnel identification", which is quite ambiguous, not to mention the fact that it simply expands the field's name. Does this ID have anything to do with VXLAN's VNI (which is 24-bit field)? As far as I can learn from the testpmd patch series, this field gets printed only if it's non-zero. Hmm. A special value of sorts? Maybe clarify this, too? Thank you. On 02/03/2021 12:42, Thomas Monjalon wrote: > 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 :) > > > -- Ivan M