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 7CF1EA0524; Thu, 7 Jan 2021 21:21:14 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 37352140DBC; Thu, 7 Jan 2021 21:21:14 +0100 (CET) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by mails.dpdk.org (Postfix) with ESMTP id 00DDE140DB4 for ; Thu, 7 Jan 2021 21:21:11 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 51CDC1692; Thu, 7 Jan 2021 15:21:09 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 07 Jan 2021 15:21:09 -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= hO6oWzwn0dr2Ia5oEa6IoS2jT1sn26jmg/C56SEZxko=; b=agLQzicvr2S6+Tl/ GJVSkte540sdr9TaO8mGiKjvb3QDQXJfDY0XlowVzVWoOwCI/lsrEXGBQSW8BrCF d4O/mPYlIWO9X32ybym4vAhibBMzjagqb6vr5rF1uKJLpiXpCoHU+3T7DMLXkRGZ 9CgimVMbfNgZ7B4+uNgSEh+XkR1+8zdS2dORxs9BhCqiHu+DB1vCzVUokmuwQla5 yJhisyOUDSJpkaGpTKwUqJtEr3ZObGp1jP3dLie3TOvGU8EZqCVZ+CRSfIIU09WC cEX6syFwYltL+IndTT+IDXe765xCm8oq00Jgj/4cFzOCa+0b2Zi2Ut/ddkKfmHY7 tMU3Bg== 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=hO6oWzwn0dr2Ia5oEa6IoS2jT1sn26jmg/C56SEZx ko=; b=Ef4DdPRByu2M0z7qh87lTj22s7KVeZ1MW7rPRv8vXAcYvWeGDH2QLFOdh 9UnNjKpR3R1JBwDHEb1C2ejvxcLTuRcabfjRLC3zh+Y+g2g9rid9WEUUj2gTP1sU rHVi0NINpEDoSbkQH+URyWH6lurXqzLq38pS9zXO+kslTLdMscxcgj1O0fZ8AfmJ QTybosr7/o9z+ZOJ7IVdafsdwsloi9RJVoh+AuqS301CECfjvEFu8akDUsuw1Mqp QZXj1yJbeTrPj6mvin0C6eO2z5Z6C4njO9FN00HUk5767/XAvwW0qFpu4QvUnZl3 jeguq/HDrIsxVIs7uLg0UpKKcFo4w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdegfedgtdduucetufdoteggodetrfdotf 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 7926A1080063; Thu, 7 Jan 2021 15:21:06 -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 21:21:04 +0100 Message-ID: <6122879.igZSR4VOTn@thomas> In-Reply-To: References: <20201218013129.25186-1-akozyrev@nvidia.com> <1964475.rDoTHco0nS@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 21:14, Alexander Kozyrev: > > 07/01/2021 17:57, Alexander Kozyrev: > > > > 07/01/2021 16:22, Alexander Kozyrev: > > > > > > 07/01/2021 16:10, Alexander Kozyrev: > > > > > > > > > > Thursday, January 7, 2021 10:18, 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? > > > > > > > > > > > > > > It is the bit offset, you can copy 20 bits out of 32 bits of IPv4 address > > for > > > > > > example. > > > > > > > > > > > > Now I'm confused. > > > > > > You mean rte_flow_action_copy_data.offset is a bit offset? > > > > > > > > > > rte_flow_action_copy_data.offset and rte_flow_action_copy_field.width > > > > > are measured in bits, right. > > > > > > > > So the offset is limited to 16 bits? > > > > How can it be useful? Is it an offset starting from the specified field? > > > > > > Why 16? It can be up to 2^16=65536 bits. Do you think that is not enough? > > > > Yes 8KB may be too small for huge packets. > > I recommend 32 bits. > Sounds good, will make it 32-bit in the implementation. > > > > And it starts from the specific packet field pointed by the Field ID, correct. > > > > I think it would be more useful as a global offset > > starting from the first bit of the packet. > The API gives you this flexibility when you specify None as the Field ID. > But Field ID is useful when you don't want to calculate the offset by yourself. > You can just say: I would like to copy IP address in the inner header (index 1), > for example, and leave offset as 0 instead of trying to figure out where it is: > set copy_field width 32 src field ipv4 index 1 offset 0 dst field tag index 0 offset 0 OK it makes sense. I think you should better explain the calculations in the doxygen comments.