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 D81D5A0524; Thu, 7 Jan 2021 18:05:57 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A2164140FBC; Thu, 7 Jan 2021 18:05:57 +0100 (CET) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by mails.dpdk.org (Postfix) with ESMTP id BE9EE140FB4 for ; Thu, 7 Jan 2021 18:05:55 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 736651529; Thu, 7 Jan 2021 12:05:54 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 07 Jan 2021 12:05:55 -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= vcrryItY6zd48LvG7HXwWT5Kt4OWEXHTQS8NPCeYocY=; b=0rI0Ff2nqyR85IaU cg5G2+M1xhFsrDHlJPefcAW4yttUJoEckis2P2A2ZUsX+ve63gAy6Min0pqkPkCT hGfwp0mde5qVbWqKEn7p0icOc/uS+Ihg0FlXaoI/6t/h6mgeP741zBgffDDfnxRs sUFRKSUbdsewxAkQ9fouuFx5jHpnBEvVEi/xjt37ym++QBr7DqIldPG23MulGTbx FNw5x0XQO+8XG2CaPoaTEOErKcgR0FVG2bAwVlnNK2iDTbHWHZbTRdfkQwwIOy+t 0Ze1RNEFlqsTQHptH2l4FypNtQL2685ZVSnyZCh2ktx1nMSGNcRPK6JOKmaPC6KF mPtyPQ== 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=vcrryItY6zd48LvG7HXwWT5Kt4OWEXHTQS8NPCeYo cY=; b=WiUnO0FrESNJL+zk/CGyNz6uvokUL3jrNC8R1daK08/saXwUBT2gUwGdC 9glTGlL53eboIgeZ88aj900BOjnRxfVP5x7D7iwJnkLzdoeToEKqOuek4R8Jq3x6 4qIiwzQu+CVb4V22AdOt8Gt8GljXuwk3R+eAlLhnXhPlm4AzKC3qIdlwTOoG46MA agi57p9xwuMsMgDqLXGi9vq7Gg8Uohmsyyttsj+zCu9uSDVsnfqsWAXfcCq10e2j zvhBbNFLyoXbSx+DFhqc+MHSKd8ku5ub3L7FdTrB1MjvSp7mmJ3hoQcjc2bu1KED sha45NGPe+8ZvKYN/jj4xM08XdsPw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdegvddgleejucetufdoteggodetrfdotf 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 0337924006D; Thu, 7 Jan 2021 12:05:51 -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 18:05:50 +0100 Message-ID: <1964475.rDoTHco0nS@thomas> In-Reply-To: References: <20201218013129.25186-1-akozyrev@nvidia.com> <2354870.U5oG32Jqq5@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 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. > 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. > > > > > > > > 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.