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 DA088A0524; Thu, 7 Jan 2021 16:17:58 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A1E61140FCF; Thu, 7 Jan 2021 16:17:58 +0100 (CET) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by mails.dpdk.org (Postfix) with ESMTP id DB463140FC7 for ; Thu, 7 Jan 2021 16:17:57 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 73C501684; Thu, 7 Jan 2021 10:17:56 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 07 Jan 2021 10:17:57 -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= Kmo7KQ/SzjAD/QFcbT2fcNXFwwpMIDx0I/+4AlBvIbA=; b=zoHtwCq1eltW94+N uXI6Fh8gnMlhyQpH1orgms719xAEIq8npWkamGgvNTyQjNYcmgd75DIzBznyLzG/ /1InJShrNzBZ+Zb+qyKbLfM8sOmfC2pGRBKRkDzTUTUN2aQM4xDimylO6Gn6dzvE K6hALFfgOYrYysjAZIZ8QKe1dvzUNIr0aBy2qG4j6Tp58hb4LgawXk6t3VCBlLUH zXCNOPX6K+OF6EjCQnaza2vVok0JFl4RWdnKS9CBDgBwa2UitGRhVSCBo3AzbAgB VT8POKanfp6K/uDR+VGyoZE45epA9Rv+TAxuh8eg226dTzxkU41ENSfUbnEXTHT1 jnJjzA== 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=Kmo7KQ/SzjAD/QFcbT2fcNXFwwpMIDx0I/+4AlBvI bA=; b=fCJTHrTbkHXu7P29Zn0p8PL+fS+WSYnHjoZz7HrtKUvBNP7ZlOdFVOwPs rG3iBzwAZd0mnUDH4X+8yhEeZgod2ds32psYy9KYnrKSs4LezUkNsSWjV6qq8MNi f0CJtfRC7XE5OTs6N2SqXUDPayz6T0+4hCNIAeVsKVyfhUz5HrSubRZIO70xks1G hJu7YxVxa1PG0ugo/9vQsdlgrjbYKlcNyYr2vGhSyWv+/44R2fB3HALVq8WXEJg/ Qt9o9sY/HRx3mwaykZguwctmNxJ4Zv8jroYloBH0RsbKn+/+GJJ8LOr0l0nGYj1r 7WaVi8FAKIIhlC51c1oA1f41huR2A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdegvddgjeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepgeejhfegjeduuddvtdehledtveffteeuffeghfekhedvgefgudff ffelgeeuhffgnecuffhomhgrihhnpehmsghufhdruggrthgrnecukfhppeejjedrudefge drvddtfedrudekgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght 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 0B0DD108005B; Thu, 7 Jan 2021 10:17:53 -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:17:52 +0100 Message-ID: <4077045.mHWWFMTU2l@thomas> In-Reply-To: References: <20201218013129.25186-1-akozyrev@nvidia.com> <6314874.LEoM74Pqvz@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 16:10, Alexander Kozyrev: > > > > Thursday, January 7, 2021 10:07, 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? > > > > 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. > > It is possible with this RFC, driver can choose what to use: id and/or offset. We can set field and index to 0, and use only offset? Then it is a byte offset from the beginning mbuf.data?