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 DD6B9A0524; Thu, 7 Jan 2021 17:54:13 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 63C3C140F7D; Thu, 7 Jan 2021 17:54:13 +0100 (CET) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by mails.dpdk.org (Postfix) with ESMTP id AC6EC140F64 for ; Thu, 7 Jan 2021 17:54:11 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 0EB9E161D; Thu, 7 Jan 2021 11:54:08 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 07 Jan 2021 11:54: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= 4o8pF1MfE6/eBDF4Yhg8gH11Dly5u3MLpmqrHlH0vBs=; b=Pzjuwy3quO39h+Vw QT/Dt84gnz8YnsK8SfPw3rYgTCRAag8mR3kvGiEko92tJmVm7oCHPaSci2kxeQY+ BH8MW0kaW46iLVaPYQL/5FOwI4WFDZF+m13Q0+C8NOyJIFVVQY7SAUJbkrwpfQPM K82sogMV13NJ87Blaf09HkNVvzX+gfPivI2W5+hwxMu9PPxplyIGkYkgtc216h1J W7+4ARvcs9inVL/nJnJYIKWqhkhL/Tpifd/i+jDXgoO8CEAeXqNvhPKDbyoIrqtv nXjtMH4V9e+aEm46rnIccMcgFO2VHPwAgbjgWLUBWmvY/SzffUuY/u9O5RZNxpTe sXjAOg== 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=4o8pF1MfE6/eBDF4Yhg8gH11Dly5u3MLpmqrHlH0v Bs=; b=cLANfE/eNDdXnWzRMl6GYMFUppWMVIBrP/Po1/aLaGWDHz5kgqhg+In7O 7+3nR0L0sr/yC2pdgfBT3DdNCYI5iPHo4qV1UhSdz6PmI/VOtT7/2z8VOUHLP234 NmyzfvEfZiw2qgW9R/+LGfJ1DpO6RPWsa/hdWuedHI0Sn9VlLRBZFtZtFljgZldS weIebG6YByKjcZ5QbDRAfyuhHL/xr5kOntyhjzmImNDgwYjCRm7D+faeN7LSraD0 NPRg3yQtfnyN4UX+wcw3ayB7/3Rw4LduhBoUSmVBH7Dp9+IETL+wTaBeCiMglnnA D8FBudMItaCUwq+bYE2mPcrc5yNpw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdegvddgleegucetufdoteggodetrfdotf 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 1DDDB240068; Thu, 7 Jan 2021 11:54: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 17:54:03 +0100 Message-ID: <2354870.U5oG32Jqq5@thomas> In-Reply-To: References: <20201218013129.25186-1-akozyrev@nvidia.com> <4077045.mHWWFMTU2l@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: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? > > > > > > 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? > Yes, I'm not inending to put any restrictions against that. > > Then it is a byte offset from the beginning mbuf.data? > Yes, but it is still bit offset, not byte offset.