From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; 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: <xms:cD_3X2j63TDOZjsHnG0LGL4uBi83UAs5W5NyS8XVuPcByRqomtbcag>
<xme:cD_3X3AqU40iBORXSEdBYG9ROvvr0TU74HhdlWGeqd1EL5mx-hoTTTIQEPzOYj1r6
eaHF4lL03Hqv-NRlA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdegvddgleejucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr
shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg
ftrfgrthhtvghrnhepgeejhfegjeduuddvtdehledtveffteeuffeghfekhedvgefgudff
ffelgeeuhffgnecuffhomhgrihhnpehmsghufhdruggrthgrnecukfhppeejjedrudefge
drvddtfedrudekgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl
fhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght
X-ME-Proxy: <xmx:cD_3X-EJKhtRGBkgkqMhdYfKzJx5WGEivdFEqlCqk5aJ5lYMCmJxsw>
<xmx:cD_3X_TGFdQvfREkWZsnLjcjl7g7Xag1d0Z6gmLYhhSo29OU9jglvw>
<xmx:cD_3XzyyOBvJLfZXOBjErz2nhn1Le4IcQA-2-GjpWY5puxI_WOhYKg>
<xmx:cj_3X-rFyCgBsmMEXri__1ZbjVdjRGgESRfdg8YBCFW5ZSd8xs-WCQ>
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 <thomas@monjalon.net>
To: Alexander Kozyrev <akozyrev@nvidia.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, Slava Ovsiienko <viacheslavo@nvidia.com>,
Ori Kam <orika@nvidia.com>, "ferruh.yigit@intel.com" <ferruh.yigit@intel.com>,
"andrew.rybchenko@oktetlabs.ru" <andrew.rybchenko@oktetlabs.ru>,
"ajit.khaparde@broadcom.com" <ajit.khaparde@broadcom.com>,
"jerinj@marvell.com" <jerinj@marvell.com>
Date: Thu, 07 Jan 2021 18:05:50 +0100
Message-ID: <1964475.rDoTHco0nS@thomas>
In-Reply-To: <BN7PR12MB27070DE7B4725B4C84487E0DAFAF0@BN7PR12MB2707.namprd12.prod.outlook.com>
References: <20201218013129.25186-1-akozyrev@nvidia.com>
<2354870.U5oG32Jqq5@thomas>
<BN7PR12MB27070DE7B4725B4C84487E0DAFAF0@BN7PR12MB2707.namprd12.prod.outlook.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
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
> > > > <thomas@monjalon.net>
> > > > > > > > > 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.