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 18083A0561; Thu, 4 Mar 2021 07:36:01 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id F28B540684; Thu, 4 Mar 2021 07:36:00 +0100 (CET) Received: from hqnvemgate26.nvidia.com (hqnvemgate26.nvidia.com [216.228.121.65]) by mails.dpdk.org (Postfix) with ESMTP id 9BC4540147 for ; Thu, 4 Mar 2021 07:35:58 +0100 (CET) Received: from hqpgpgate101.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate26.nvidia.com (using TLS: TLSv1.2, DES-CBC3-SHA) id ; Wed, 03 Mar 2021 22:35:57 -0800 Received: from HQMAIL107.nvidia.com ([172.20.161.6]) by hqpgpgate101.nvidia.com (PGP Universal service); Wed, 03 Mar 2021 22:35:57 -0800 X-PGP-Universal: processed; by hqpgpgate101.nvidia.com on Wed, 03 Mar 2021 22:35:57 -0800 Received: from DRHQMAIL107.nvidia.com (10.27.9.16) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 4 Mar 2021 06:35:57 +0000 Received: from [172.27.0.124] (172.20.145.6) by DRHQMAIL107.nvidia.com (10.27.9.16) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 4 Mar 2021 06:35:45 +0000 To: Ivan Malov , Thomas Monjalon , Gregory Etelson CC: , , , , , 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> <4a5ec329-bd91-e9d6-7578-be4e093bffa4@oktetlabs.ru> From: Eli Britstein Message-ID: Date: Thu, 4 Mar 2021 08:35:39 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <4a5ec329-bd91-e9d6-7578-be4e093bffa4@oktetlabs.ru> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: [172.20.145.6] X-ClientProxiedBy: HQMAIL105.nvidia.com (172.20.187.12) To DRHQMAIL107.nvidia.com (10.27.9.16) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1614839757; bh=UKsq8woytVgYtIIS8UbGSBrpSjr+qDMa/Dppol50rxM=; h=X-PGP-Universal:Subject:To:CC:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Content-Language:X-Originating-IP: X-ClientProxiedBy; b=C94qYvI2t9ejudxSf/3uMn8T0C0y6btrwx+xYu9m6KqCJaUlf7//BtTRwSS7L0E9s lFc2zTyTOZydI3WNt8zXWmUFuZIkyvwculQ93t0aPRb+xtc0WD6X6LMaAPYbyg9Asb 5Ba79UEvLS9bSgErmxDO/6DNu/nX18HjgREZxg8AriZXftmALpYQbo43UTVk7MYZZn ZD8JDM9j3LG/f80wwUKMSQvtMT2BdrZ5T2wElbnvGFGxyKB6sfazRDM1HQMA4gQ24p 1SjXIWRPyJSMe+uC1o4TOcvP25bXGL/EFyX2V1aagnJbv5tcd3yHxIZpNEgkX5GljH mNXPQhwuhMLgQ== 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" On 3/3/2021 4:03 PM, Ivan Malov wrote: > Hi, > > Could someone please also clarify the meaning (from PMD standpoint and=20 > from application's standpoint) of the 64-bit field "tun_id" in=20 > "rte_flow_tunnel"? The current comment reads: "Tunnel identification",=20 > which is quite ambiguous, not to mention the fact that it simply=20 > expands the field's name. Does this ID have anything to do with=20 > VXLAN's VNI (which is 24-bit field)? rte_flow_tunnel struct is the tunnel details communicated between the=20 application and PMD when applying flows, and from the PMD to the=20 application upon miss. The fields in it are porting of the kernel's 'struct ip_tunnel_key'. See=20 https://elixir.bootlin.com/linux/latest/source/include/net/ip_tunnels.h#L40 Regarding 'tun_id' - yes. In case of VXLAN tunnel it stores the VNI. > > As far as I can learn from the testpmd patch series, this field gets=20 > printed only if it's non-zero. Hmm. A special value of sorts? Maybe=20 > 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: >>> =C2=A0 > Applications wishing to offload tunneled traffic are required = to=20 >>> use >>> =C2=A0 > the rte_flow primitives, such as group, meta, mark, tag, and=20 >>> others to >>> =C2=A0 > model their high-level objects.=C2=A0 The hardware model desig= n 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=3D1" both for the "tunne= l >>> 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? >>> >>> =C2=A0 > The first VXLAN packet that arrives matches the rule in group = 0 and >>> =C2=A0 > jumps to group 3.=C2=A0 In group 3 the packet will miss since = there=20 >>> 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=20 >>> 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 :) >> >> >> >