From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4DBE0A04DB; Thu, 15 Oct 2020 01:55:52 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E29351DA80; Thu, 15 Oct 2020 01:55:49 +0200 (CEST) Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) by dpdk.org (Postfix) with ESMTP id A40D41C2DB for ; Thu, 15 Oct 2020 01:55:47 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 49CA95802A6; Wed, 14 Oct 2020 19:55:47 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Wed, 14 Oct 2020 19:55:47 -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= 7Y0gWupE+ZlD1woIDAkrnZuy8ieXtgpkDY1irO+AsJg=; b=Xc0anE6wwwOGPLxJ WoNrwgB2w40oKbICiPdCQiO9nr6aHixTxPkHc9H8HL7rNd66JKVPoNro+Uz53NZ5 z7pg/oQwD7j5ghl2MCVpgwW0J3csMZr3fx70/E44AhtqmBOlRTKOUgRvh+h5DNYO wRUEdXkShBrnqcr+EFLfMRJvWV3m+BbW905lj0sDjF2dGNJps1i2diA8L36hoj1A aeBQkQhcEz2PAZpTv2ovQxqyI+2EyklGZ/n3b2c9SrIgDC1ghJrJRb/dE+cr35a7 KGOMsTgneMj9nNVTN634QyYIn0RpL4IqqK2F16LbIWIIrXd4xFtky19Z30xThu1d NIlEbg== 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=fm1; bh=7Y0gWupE+ZlD1woIDAkrnZuy8ieXtgpkDY1irO+As Jg=; b=jsNyoaNyVWM7fNeOfv9kIy85juYlmeFHGoPJUfQHt+SD4R9WXagmrw3gb EY7gB906eHrFL+0g6Fe0+O1EcsSgNmqB6FzejV2H8mf8u3z5w36FRnVYfbb2h+dR iXvdKmqu2Ce/MpRV84g62+mYM6YRjjAt9UYfnmpPgYnaUupNeJbIH8ZvEV48MuwZ ragxUUXEe3wHEcp9INoMwEjlW8DysUSnTeWzmCjd2RFjarQow9NpLziI044dFtxw Ub7Xw8WhL811wm+TTX8Rzip9TFhqUfOBbg6xkuw4HYEW5819hXC5T4BwdwTDknGp NVoT/41M1EryGucATrM/CrqpGXVUQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedriedvgddvjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth 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 37CE03280065; Wed, 14 Oct 2020 19:55:44 -0400 (EDT) From: Thomas Monjalon To: Gregory Etelson Cc: dev@dpdk.org, matan@nvidia.com, rasland@nvidia.com, ozsh@nvidia.com, ajit.khaparde@broadcom.com, Eli Britstein , Ori Kam , Viacheslav Ovsiienko , Ray Kinsella , Neil Horman , Ferruh Yigit , Andrew Rybchenko , asafp@nvidia.com Date: Thu, 15 Oct 2020 01:55:43 +0200 Message-ID: <3193854.PZMSdADrpi@thomas> In-Reply-To: <20201004135040.10307-3-getelson@nvidia.com> References: <20200625160348.26220-1-getelson@mellanox.com> <20201004135040.10307-1-getelson@nvidia.com> <20201004135040.10307-3-getelson@nvidia.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v4 2/4] ethdev: tunnel offload model X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" Formatting review below (someone has to do it): 04/10/2020 15:50, Gregory Etelson: > --- a/doc/guides/prog_guide/rte_flow.rst > +++ b/doc/guides/prog_guide/rte_flow.rst > @@ -3034,6 +3034,111 @@ operations include: > +Tunneled traffic offload > +~~~~~~~~~~~~~~~~~~~~~~~~ > + > +Provide software application with unified rules model for tunneled traffic > +regardless underlying hardware. > + > + - The model introduces a concept of a virtual tunnel port (VTP). Given the API does use this terminology, it is confusing to find this wording in the doc. > + - The model uses VTP to offload ingress tunneled network traffic > + with RTE flow rules. > + - The model is implemented as set of helper functions. Each PMD > + implements VTP offload according to underlying hardware offload > + capabilities. Applications must query PMD for VTP flow > + items / actions before using in creation of a VTP flow rule. > + > +The model components: > + > +- Virtual Tunnel Port (VTP) is a stateless software object that > + describes tunneled network traffic. VTP object usually contains > + descriptions of outer headers, tunnel headers and inner headers. > +- Tunnel Steering flow Rule (TSR) detects tunneled packets and > + delegates them to tunnel processing infrastructure, implemented > + in PMD for optimal hardware utilization, for further processing. > +- Tunnel Matching flow Rule (TMR) verifies packet configuration and > + runs offload actions in case of a match. I'm not a fan of all those acronyms. It makes reading more difficult in my opinion. > + > +Application actions: > + > +1 Initialize VTP object according to tunnel network parameters. > + > +2 Create TSR flow rule. > + > +2.1 Query PMD for VTP actions. Application can query for VTP actions more than once. > + > + .. code-block:: c > + > + int > + rte_flow_tunnel_decap_set(uint16_t port_id, > + struct rte_flow_tunnel *tunnel, > + struct rte_flow_action **pmd_actions, > + uint32_t *num_of_pmd_actions, > + struct rte_flow_error *error); > + > +2.2 Integrate PMD actions into TSR actions list. > + > +2.3 Create TSR flow rule. > + > + .. code-block:: console > + > + flow create group 0 match {tunnel items} / end actions {PMD actions} / {App actions} / end Not sure about the testpmd syntax here. Is it bringing a value compared to some text description? > + > +3 Create TMR flow rule. > + > +3.1 Query PMD for VTP items. Application can query for VTP items more than once. > + > + .. code-block:: c > + > + int > + rte_flow_tunnel_match(uint16_t port_id, > + struct rte_flow_tunnel *tunnel, > + struct rte_flow_item **pmd_items, > + uint32_t *num_of_pmd_items, > + struct rte_flow_error *error); > + > +3.2 Integrate PMD items into TMR items list. > + > +3.3 Create TMR flow rule. > + > + .. code-block:: console > + > + flow create group 0 match {PMD items} / {APP items} / end actions {offload actions} / end > + > +The model provides helper function call to restore packets that miss > +tunnel TMR rules to its original state: > + > +.. code-block:: c > + > + int > + rte_flow_get_restore_info(uint16_t port_id, > + struct rte_mbuf *mbuf, > + struct rte_flow_restore_info *info, > + struct rte_flow_error *error); > + > +rte_tunnel object filled by the call inside > +``rte_flow_restore_info *info parameter`` can be used by the application > +to create new TMR rule for that tunnel. > + > +The model requirements: Should it be a section title? > + > +Software application must initialize > +rte_tunnel object with tunnel parameters before calling > +rte_flow_tunnel_decap_set() & rte_flow_tunnel_match(). It is preferred having code symbols between double backquotes. > + > +PMD actions array obtained in rte_flow_tunnel_decap_set() must be > +released by application with rte_flow_action_release() call. > +Application can release the actionsfter TSR rule was created. typo: actionsfter > + > +PMD items array obtained with rte_flow_tunnel_match() must be released > +by application with rte_flow_item_release() call. Application can > +release the items after rule was created. However, if the application > +needs to create additional TMR rule for the same tunnel it will need > +to obtain PMD items again. > + > +Application cannot destroy rte_tunnel object before it releases all > +PMD actions & PMD items referencing that tunnel. [...] > --- a/doc/guides/rel_notes/release_20_11.rst > +++ b/doc/guides/rel_notes/release_20_11.rst > @@ -62,6 +62,15 @@ New Features > * Added support for 200G PAM4 link speed. > * Added support for RSS hash level selection. > * Updated HWRM structures to 1.10.1.70 version. > +* **Flow rules allowed to use private PMD items / actions.** > + > + * Flow rule verification was updated to accept private PMD > + items and actions. This should be in the previous patch, but not sure it's worth noting at all. > + > +* **Added generic API to offload tunneled traffic and restore missed packet.** > + > + * Added a new hardware independent helper API to RTE flow library that > + offloads tunneled traffic and restores missed packets. Here and elsewhere, "hardware independent" is implied for rte_flow API. Please write "flow API" or "rte_flow". This block should be before driver ones, with other ethdev features. > --- a/lib/librte_ethdev/rte_ethdev_version.map > +++ b/lib/librte_ethdev/rte_ethdev_version.map > @@ -226,6 +226,12 @@ EXPERIMENTAL { > rte_tm_wred_profile_add; > rte_tm_wred_profile_delete; > > + rte_flow_tunnel_decap_set; > + rte_flow_tunnel_match; > + rte_flow_get_restore_info; > + rte_flow_tunnel_action_decap_release; > + rte_flow_tunnel_item_release; It is for 20.11 now, so should be placed below. > + > # added in 20.11 > rte_eth_link_speed_to_str; > rte_eth_link_to_str;