From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (xvm-189-124.dc0.ghst.net [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 16937A0524; Thu, 7 Jan 2021 16:06:45 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DDDD2140FB7; Thu, 7 Jan 2021 16:06:44 +0100 (CET) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by mails.dpdk.org (Postfix) with ESMTP id C3D98140FB3 for ; Thu, 7 Jan 2021 16:06:43 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 708A011F1; Thu, 7 Jan 2021 10:06:42 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 07 Jan 2021 10:06:43 -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= yBBstP63lyp8m0WCJIUgTUdvSzxnA8dWzeljUs1VTAo=; b=Isw1GZNoCZqMbSzV HZFTyTc9pAMbuoGPo4gur4fTBMpRD/mMizlNKOFKBOzj/B9eImIlCCGxfR+T6rXi FtwyxcjB/1PelLk7ziKjUSGerufifV8cd0XcMAnLesEAXK7c8mH3Jvcsv7evG+te 8G0sJ95mZCk2i/DqKDjeEa0mrvM1vRxRhosHhZR4Mqv8TLXIPC9IKBFTtXFPFrIK 3sqDag4+7DFTOgSN7TTqXwliU2h9tUjYPC+d7JzXObzP7W6O+H6lAO746pswUaB/ xHTBgek0uBKdHtrV9svG0DaxGHcuGBM/kq/VSG+ChsY3YNSa1bX7QQpKxhZ/NGzC djaM/g== 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=yBBstP63lyp8m0WCJIUgTUdvSzxnA8dWzeljUs1VT Ao=; b=FZY7VpNpczpSs2pJahctvIOlUzTYOmlfPB4MxFE7bfHebsjFfpLR9viyd zWrQN3jzAnSZhFGi79SoBNV/IhLm8kM1pmzs71BKypYvgLQ6PNu7T2pRnlvHGOiP eraAjA/PFhdj6jTtkKryXP/Rc1+sYK6Jl9Xs5iFa+1bB/OdYyvbB5oI3z4ViHzTi orZhFu/se1BkVkjskkqVn9s7VUmNt7W0QSAQM45HItR709+/M3tzW9PPFVFlTBgw KQlttsaeNUgBaQZolaknF/mglXe8wdIYfg2bOVwCyolrb8njjFv9+6HvWuYNylUb Gc4w2E1QexJ225R4CarrRtZzTGMwg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdegvddgjeefucetufdoteggodetrfdotf 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 35E15240057; Thu, 7 Jan 2021 10:06:40 -0500 (EST) From: Thomas Monjalon To: Alexander Kozyrev Cc: dev@dpdk.org, Slava Ovsiienko , Ori Kam , ferruh.yigit@intel.com, andrew.rybchenko@oktetlabs.ru, ajit.khaparde@broadcom.com, jerinj@marvell.com Date: Thu, 07 Jan 2021 16:06:39 +0100 Message-ID: <6314874.LEoM74Pqvz@thomas> In-Reply-To: References: <20201218013129.25186-1-akozyrev@nvidia.com> <69996023.yYu3UIiVKq@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [RFC] ethdev: introduce copy_field rte flow action 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" 07/01/2021 15:17, Alexander Kozyrev: > > Tuesday, January 5, 2021 17:17, Thomas Monjalon > > > RTE Flows API lacks the ability to save an arbitrary header field in > > > order to use it later for advanced packet manipulations. Examples > > > include the usage of VxLAN ID after the packet is decapsulated or > > > storing this ID inside the packet payload itself or swapping an > > > arbitrary inner and outer packet fields. > > > > > > The idea is to allow a copy of a specified number of bits form any > > > packet header field into another header field: > > > RTE_FLOW_ACTION_TYPE_COPY_FIELD with the structure defined below. > > > > > > struct rte_flow_action_copy_field { > > > struct rte_flow_action_copy_data dest; > > > struct rte_flow_action_copy_data src; > > > uint16_t width; > > > }; > > > > > > Arbitrary header field (as well as mark, metadata or tag values) can be > > > used as both source and destination fields. This way we can save an > > > arbitrary header field by copying its value to a tag/mark/metadata or > > > copy it into another header field directly. tag/mark/metadata can also > > > be used as a value to be stored in an arbitrary packet header field. > > > > > > struct rte_flow_action_copy_data { > > > enum rte_flow_field_id field; > > > uint16_t index; > > > uint16_t offset; > > > }; > > > > > > The rte_flow_field_id specifies the particular packet field (or > > > tag/mark/metadata) to be used as a copy source or destination. > > > The index gives access to inner packet headers or elements in the tags > > > array. The offset allows to copy a packet field value into the payload. > > > > So index is in reality the layer? How is it numbered exactly? > > It is a layer for packet fields, inner headers get higher number index. > But is it also an index in the TAG array, so the name comes from it. Sorry it is not obvious. Please describe the exact numbering in tunnel and VLAN cases. > > What is the field id if an offset is given? > > Field ID stays the same, you can specify a small offset to copy just a few bits > from the entire packet field or a big offset to move to completely different area. I don't understand what is an offset then. Isn't it the byte or bit where the copy start? Do you handle sizes smaller than a byte? > > Can we say that a field id can always be replaced by an offset? > > Not really. You can use offset to jump around packet fields for sure, but it is going to be > hard and cumbersome to calculate all the offsets for that. Field ID is much more convenient. I think it depends for who. For some use cases, it may be easier to pass an offset. For some drivers, it may be more efficient to directly manage offsets.