From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6CDBAA04B5; Tue, 12 Jan 2021 15:15:44 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2F682140DD6; Tue, 12 Jan 2021 15:15:44 +0100 (CET) Received: from nat-hk.nvidia.com (nat-hk.nvidia.com [203.18.50.4]) by mails.dpdk.org (Postfix) with ESMTP id 034AB140DCC for ; Tue, 12 Jan 2021 15:15:41 +0100 (CET) Received: from HKMAIL104.nvidia.com (Not Verified[10.18.92.77]) by nat-hk.nvidia.com (using TLS: TLSv1.2, AES256-SHA) id ; Tue, 12 Jan 2021 22:15:40 +0800 Received: from HKMAIL101.nvidia.com (10.18.16.10) by HKMAIL104.nvidia.com (10.18.16.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 12 Jan 2021 14:15:36 +0000 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.176) by HKMAIL101.nvidia.com (10.18.16.10) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 12 Jan 2021 14:15:36 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MosDI/FwYQI92LmFWgkjjhZ0LcEaaui7YUzdhoo87q2D2wP72mJW6MJWgaLCfA3E1aDqevboycK3qb4yTHIRokmtEcIM7XoeSIhX19nSPqibfh2JHy2Hh3ITgU3oK7B8LbFxHMjHvE0r7JlDlS3tzr8mgFxvmwZZPVf0etuVdPFnIx6bOq+MRLW0zDbMfSvSLzO53bwEqd/zj83a3trPS833xfWvEhCdJrAKONV6OAT5uUV9HOrLezc0LhSIYmycSJO3llohDD+vmjXopjTzlXiQh2dPXar0lXR1oLvEn4y/iI+IAA6inSlPqpTAe8mRkEHWTC0atd5JenmBhjhIRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NgLNJhMJebW8bYeBn2BLIXU1WMrnOC+aPKgw/JcC920=; b=aiensCf392iJ4m/VwEkjV8hBKca4f10nE2knB2E6bOvKnjepVp+NJXyMHmNLtbMydoX7W2w5F71rifmIUueMfqM6BWpuW81jiodzdSVFcrRl/Dw0BncWhZc/TctGmtnX6opxkZjytb2fm0egjF1JXC27R3V9w5f6BbjmDkl5Sre18tbvMsTkBCrcWoRWZ61Zfa8NCRTVcXRZM1qHEQkQsyIUbgf70u1dxsGNLyCFhPhKfwJIKtwdKq134AaBri7/j8gGvsKrV+uvP4O9CltVTP3lTJSkX3T7RcFa/g6HRtWEfEJbObFYrueMhUYsH2Wi+A7Z9ofC6EuAtPI4Ieu8uA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none Received: from BN7PR12MB2707.namprd12.prod.outlook.com (2603:10b6:408:2f::29) by BN8PR12MB3524.namprd12.prod.outlook.com (2603:10b6:408:68::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.9; Tue, 12 Jan 2021 14:15:33 +0000 Received: from BN7PR12MB2707.namprd12.prod.outlook.com ([fe80::c44c:1e37:b3f4:e968]) by BN7PR12MB2707.namprd12.prod.outlook.com ([fe80::c44c:1e37:b3f4:e968%6]) with mapi id 15.20.3742.012; Tue, 12 Jan 2021 14:15:33 +0000 From: Alexander Kozyrev To: Ori Kam , "dev@dpdk.org" CC: Slava Ovsiienko , NBU-Contact-Thomas Monjalon , "ferruh.yigit@intel.com" , "andrew.rybchenko@oktetlabs.ru" Thread-Topic: [PATCH] ethdev: introduce generic copy rte flow action Thread-Index: AQHW5yawvE2uZ+f89ES7X13ENcjmVKokBh+w Date: Tue, 12 Jan 2021 14:15:33 +0000 Message-ID: References: <20210108063234.7679-1-akozyrev@nvidia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nvidia.com; dkim=none (message not signed) header.d=none;nvidia.com; dmarc=none action=none header.from=nvidia.com; x-originating-ip: [2607:fea8:e380:d8e0:5ab:e379:c2d4:aea9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b8eb09bb-ea21-426f-c1b6-08d8b7048642 x-ms-traffictypediagnostic: BN8PR12MB3524: x-ld-processed: 43083d15-7273-40c1-b7db-39efd9ccc17a,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ghiPKxA6isgH4eduC8HIdUjdsWxw5PSQt/igCuGn+LT5lzkiz+sI/p1mBKhEwUfXl3XhOAy+unB14tSmTO2sqzkZnBOix6VFkEIVmaUrnSPgzvx4xaDaoUN3QABTcapGRAYABSgHab/3alarAyE65rKXoL40uGJux6hEApPoE0OwAMgvxPEN1PEZv5j9yaKenPxSE2xXybmHMz2FQWfPc5FCt/6A3cGXcARn7fC/wtkF9XfaW7DXtaL8IO7DO67iVm4MlsAYvonslswhMQF6/7v9uGK+V8yOzNULKJHDvSLxMU4vn7lCjT8R+raERGtKhV+O9k09yNo0MiyG2Anec9WcsbRkjs4V6mHo9ljHDSU50gProQllwNVPs1QxCk+akBj+psPEtFWTCzg1z72gmOU6O6UsO9mThLNrzvwH28oosG+22z3REXirRx/hNl5wr7w2UVlJJ8rul9XMs7XXvThhL+KbpunSuBk4Q2FobDDJ0lTYy4w5lXrMomHHUuPdAnTeplVON5se65pIb4E5TA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR12MB2707.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(376002)(396003)(366004)(136003)(346002)(66946007)(83380400001)(76116006)(8676002)(966005)(53546011)(6506007)(64756008)(66476007)(86362001)(33656002)(66556008)(66446008)(8936002)(52536014)(478600001)(54906003)(4326008)(110136005)(316002)(55016002)(9686003)(186003)(7696005)(45080400002)(5660300002)(2906002)(71200400001)(41533002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?eG5q7OlgJsgh0A67Z6/+2s+lT9MioaNaiyIatnblTTH2JLsMtpON70Lpito0?= =?us-ascii?Q?kyw6PtUOWfl6rL5AUgwz/yeW1zr6NbnOGkNZx2qcsOlL4z7oA2BmEEH6kNYB?= =?us-ascii?Q?GIQ6vr8+xVrJY+DhCOlTBZO+0xHrtb/550c7sbqI80aoUXEdLb4gR/B84db1?= =?us-ascii?Q?BR97BMwRpZWNm9VTMITveDR7D56vONyubrtuKO29YICJ79QeyJDwv8O6z2Db?= =?us-ascii?Q?mkepwAiFDBL9WpyQwsP+yXTJpIlJ504T4xKulr/LOG/bZFbkd0SbVVdCMMQz?= =?us-ascii?Q?VAAO40TjcfwAm2sncevnYgHVpH0kHSGJUu+OHVHq3ghaqpZDSWZ4oCWzXB/h?= =?us-ascii?Q?xsBqaCmqw6g9XbHz/0pu2jecJHkwmFE0dH4x+PHPEfj4gux86IGxcWzQXt1L?= =?us-ascii?Q?XMtkw4HkFmD6Y3PWMHbW7QDwJspJD0gWIy62qaBtBmk1r7tXEG+sGfWeLJGx?= =?us-ascii?Q?QByRT+2gRR5RjQ+XDhJdbScwVs6cSU0ydtv0UENNctHSLpUFv7X4V01yxtps?= =?us-ascii?Q?+dbOmDRMTE/K+/fGjLUxNhZMahos0qNNneFkxCzvxLmiUk3GECBy0unA8mw+?= =?us-ascii?Q?E/CHEwqg+4oTYZw7IOHARcGX2+sU93AN2IwmKdRHBStgfAJzFUDjj8Gqrq7I?= =?us-ascii?Q?m5rWQbutpmyRI+fesOzJw7Y+LQqAJIIZmR9ELDFXG3nVp4IPW9ZuvvIgvai5?= =?us-ascii?Q?Vjvnflub2ffwnRHYLIdSxYoHuWS+qg2a7eCpeFu8v/HeN31Qwf6geD9A4p4S?= =?us-ascii?Q?Eg1HlCpoqPNArYU9jlANBC5C3EU1XfWbK5vkWCaHa5ay3rXXlZA1ZJUiCGEN?= =?us-ascii?Q?g+iK4bWUBGfzWyMUjXcNhmJF0P83QnOWxo/tiI+dw5xTatPpg/56/lfzlgoS?= =?us-ascii?Q?aNKdCzCH0xL638uC3iys6a0OFkw0znrO16mW3bMJIqm3HQPNLYk+SfBBdHhq?= =?us-ascii?Q?4iAakmJ3v0Sfvs5/cJjyTJGpqtJ5UNCidHY15RRGl6fNxNDfOPgBCAI0d/D0?= =?us-ascii?Q?YRv1pwdegRnohKBpweAlqEuAvmuDLhoD1DVDKuR/GVPbc2c=3D?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN7PR12MB2707.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b8eb09bb-ea21-426f-c1b6-08d8b7048642 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2021 14:15:33.1940 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: T/eiSGO0Jav8LbQxpnzR0YSsAex3Wnn/yhx/zpW+kSM8m5vAh7nuoQdZsmLiR5bVlo/dk2Cwzh+GCKpIB3z3kQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR12MB3524 X-OriginatorOrg: Nvidia.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1610460940; bh=NgLNJhMJebW8bYeBn2BLIXU1WMrnOC+aPKgw/JcC920=; h=ARC-Seal:ARC-Message-Signature:ARC-Authentication-Results:From:To: CC:Subject:Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:authentication-results:x-originating-ip: x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-ms-traffictypediagnostic:x-ld-processed: x-ms-exchange-transport-forked:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-ms-exchange-senderadcheck: x-microsoft-antispam:x-microsoft-antispam-message-info: x-forefront-antispam-report:x-ms-exchange-antispam-messagedata: Content-Type:Content-Transfer-Encoding:MIME-Version: X-MS-Exchange-CrossTenant-AuthAs: X-MS-Exchange-CrossTenant-AuthSource: X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped:X-OriginatorOrg; b=jfweMpVPn5ij/8P/NHtOQ/4oUx7ZDEU0+vTIL4s+tFwSmZfK9u7kwANq4I4DHRq4J wPRBo8nHLqcXJD6WEboruphQhF7SC/1MYFaVRsM3AgfxlEcqYbl3XZTNiZ2zwD0M2m w6Bsu5jc4IApM6Ozwp8pkp03rJd/rEa1ga4Tgfm4p5oD9QWknQUPLpj9ZEHauj2ztX CS5SpgF6biwq/EEw2F1hHdhUplFFIR+OGthszV909w8MJ8a6eHgSvcUi9RLLYEp6CF xXFRtY13/byfMsSNCR6tyB4rum28YXFJwZ7dIuo/PYKLJfD1ibrDJxlhs2zwW6Tm// hNPWDiXbsK4Ig== Subject: Re: [dpdk-dev] [PATCH] ethdev: introduce generic copy 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" > From: Ori Kam on Sunday, January 10, 2021 3:01 > Hi Alexander, >=20 > I guess that the test-pmd part will be available later right? Yes, please take a look at v2 version for testpmd implementation. > > -----Original Message----- > > From: Alexander Kozyrev > > Sent: Friday, January 8, 2021 8:33 AM > > Subject: [PATCH] ethdev: introduce generic copy rte flow action > > > > Implement a generic copy flow API to allow copying of an arbitrary > > header field (as well as mark, metadata or tag) to another item. > > > > This generic copy mechanism removes the necessity to implement a > > separate RTE Flow action every time we need to modify a new packet > > field in the future. A user-provided value can be used from a > > specified tag/metadata or directly copied from other packet field. > > > > The number of bits to copy as well as the offset to start from can > > be specified to allow a partial copy or copy into an arbitrary > > place in a packet for greater flexibility. > > >=20 > Since the question why you are using enum and not just offset from > the start of the packet, was discussed and raised by number of people it = will be > best > if it will appear in the commit log, at least the advantages to this > implementation. Ok, will add to v3 commit message. > > RFC: > > > https://nam11.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fpatche= s. > d > > > pdk.org%2Fpatch%2F85384%2F&data=3D04%7C01%7Corika%40nvidia.com% > > > 7Cd04c2e49c3a840994da408d8b39f3304%7C43083d15727340c1b7db39efd9cc > > > c17a%7C0%7C0%7C637456843629116269%7CUnknown%7CTWFpbGZsb3d8eyJ > > > WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C > > 1000&sdata=3D85096rASBtzbjU42pV6sPkl3nVt5HlR6%2BL9nxI3qgFA%3D&a > > mp;reserved=3D0 > > > > Signed-off-by: Alexander Kozyrev > > --- > > doc/guides/prog_guide/rte_flow.rst | 35 ++++++++++++++++++ > > lib/librte_ethdev/rte_flow.c | 1 + > > lib/librte_ethdev/rte_flow.h | 59 ++++++++++++++++++++++++++++++ > > 3 files changed, 95 insertions(+) > > > > diff --git a/doc/guides/prog_guide/rte_flow.rst > > b/doc/guides/prog_guide/rte_flow.rst > > index 86b3444803..b737ff9dad 100644 > > --- a/doc/guides/prog_guide/rte_flow.rst > > +++ b/doc/guides/prog_guide/rte_flow.rst > > @@ -2766,6 +2766,41 @@ The behaviour of the shared action defined by > > ``action`` argument of type > > | no properties | > > +---------------+ > > > > +Action: ``COPY_ITEM`` > > +^^^^^^^^^^^^^^^^^^^^^ > > + > > +Copy ``width`` bits from ``src`` item to ``dst`` item. > > + > > +An arbitrary header field (as well as mark, metadata or tag values) > > +can be used as both source and destination items as set by ``item``. > > + >=20 > For tag I think you should also use the index right? Right, index is here to access any element in the tag array in addition to outermost or any inner packet header fields. Will specify explicitly in the= doc. > > +Inner packet header fields can be accessed using the ``index`` and > > +it is possible to start the copy from the ``offset`` bits in an item. >=20 > Please specify what means index 0 /1 ... 0 is outer most? Inner most? > You can look at the RSS level for reference. > I think it will be best to use the same values. 0 is outer most, of course, I'Il add some clarification about that. > What happens if we want to copy between different sizes? > for example copy IPV6 src to number of tags? I assume we will be using of= fset > and > split the copy command to number of actions right? That is the correct understanding. We can utilize 4 copy_item actions in th= is case to copy 32-bits of an IPv6 SRC at the time (specifying different offsets) to 4= different Tag fields. > > + > > +.. _table_rte_flow_action_copy_item: > > + > > +.. table:: COPY_ITEM > > + > > + +-----------------------------------------+ > > + | Field | Value | > > + +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ > > + | ``dst`` | destination item | > > + | ``src`` | source item | > > + | ``width`` | number of bits to copy | > > + +---------------+-------------------------+ > > + > > +.. _table_rte_flow_action_copy_data: > > + > > +.. table:: destination/source item definition > > + > > + +----------------------------------------------------------+ > > + | Field | Value | > > + +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ > > + | ``item`` | ID of a packet field/mark/metadata/tag | > > + | ``index`` | index of outer/inner header or tag array | > > + | ``offset`` | number of bits to skip during the copy | > > + +---------------+------------------------------------------+ > > + > > Negative types > > ~~~~~~~~~~~~~~ > > > > diff --git a/lib/librte_ethdev/rte_flow.c b/lib/librte_ethdev/rte_flow.= c > > index a06f64c271..fdbabefc47 100644 > > --- a/lib/librte_ethdev/rte_flow.c > > +++ b/lib/librte_ethdev/rte_flow.c > > @@ -176,6 +176,7 @@ static const struct rte_flow_desc_data > > rte_flow_desc_action[] =3D { > > MK_FLOW_ACTION(SET_IPV6_DSCP, sizeof(struct > > rte_flow_action_set_dscp)), > > MK_FLOW_ACTION(AGE, sizeof(struct rte_flow_action_age)), > > MK_FLOW_ACTION(SAMPLE, sizeof(struct rte_flow_action_sample)), > > + MK_FLOW_ACTION(COPY_ITEM, sizeof(struct > > rte_flow_action_copy_item)), > > /** > > * Shared action represented as handle of type > > * (struct rte_flow_shared action *) stored in conf field (see > > diff --git a/lib/librte_ethdev/rte_flow.h b/lib/librte_ethdev/rte_flow.= h > > index 0977a78270..0540c861fb 100644 > > --- a/lib/librte_ethdev/rte_flow.h > > +++ b/lib/librte_ethdev/rte_flow.h > > @@ -2198,6 +2198,16 @@ enum rte_flow_action_type { > > * struct rte_flow_shared_action). > > */ > > RTE_FLOW_ACTION_TYPE_SHARED, > > + > > + /** > > + * Copy a packet header field, tag, mark or metadata. > > + * > > + * Allow saving an arbitrary header field by copying its value > > + * to a tag/mark/metadata or copy it into another header field. > > + * > > + * See struct rte_flow_action_copy_item. > > + */ > > + RTE_FLOW_ACTION_TYPE_COPY_ITEM, > > }; > > > > /** > > @@ -2791,6 +2801,55 @@ struct rte_flow_action_set_dscp { > > */ > > struct rte_flow_shared_action; > > > > +enum rte_flow_item_id { > > + RTE_FLOW_ITEM_NONE =3D 0, > > + RTE_FLOW_ITEM_MAC_DST, > > + RTE_FLOW_ITEM_MAC_SRC, > > + RTE_FLOW_ITEM_VLAN_TYPE, > > + RTE_FLOW_ITEM_VLAN_ID, > > + RTE_FLOW_ITEM_MAC_TYPE, > > + RTE_FLOW_ITEM_IPV4_DSCP, > > + RTE_FLOW_ITEM_IPV4_TTL, > > + RTE_FLOW_ITEM_IPV4_SRC, > > + RTE_FLOW_ITEM_IPV4_DST, > > + RTE_FLOW_ITEM_IPV6_HOPLIMIT, > > + RTE_FLOW_ITEM_IPV6_SRC, > > + RTE_FLOW_ITEM_IPV6_DST, > > + RTE_FLOW_ITEM_TCP_PORT_SRC, > > + RTE_FLOW_ITEM_TCP_PORT_DST, > > + RTE_FLOW_ITEM_TCP_SEQ_NUM, > > + RTE_FLOW_ITEM_TCP_ACK_NUM, > > + RTE_FLOW_ITEM_TCP_FLAGS, > > + RTE_FLOW_ITEM_UDP_PORT_SRC, > > + RTE_FLOW_ITEM_UDP_PORT_DST, > > + RTE_FLOW_ITEM_VXLAN_VNI, > > + RTE_FLOW_ITEM_GENEVE_VNI, > > + RTE_FLOW_ITEM_GTP_TEID, > > + RTE_FLOW_ITEM_TAG, > > + RTE_FLOW_ITEM_MARK, > > + RTE_FLOW_ITEM_META, > > +}; >=20 > I don't think this name is good since it not rte_flow_item this is just i= nternal > enumeration > for this action. Will rename to rte_flow_action_copy_item_id in v3? Is this ok? > > + > > +struct rte_flow_action_copy_data { > > + enum rte_flow_item_id item; > > + uint32_t index; > > + uint32_t offset; >=20 > Why use 32 bits? Since this copy only one register with max len of 32 bit= . > The max offset can 31? Same for the index. This extends the flexibility of the copy API. This way you can modify any p= lace in a packet as you desire by specifying RTE_FLOW_ITEM_NONE to start with th= e beginning of a packet and choosing a particular offset value to point in a = desired place. And since packet length can be pretty big we need to accommodate this. Do you think this flexibility is not necessary and we should bound the offs= et to the length of a selected packet field only? Index is 32 bit for the same field = in RSS. > > +}; > > + > > +/** > > + * RTE_FLOW_ACTION_TYPE_COPY_ITEM > > + * > > + * Copies a specified number of bits from a source header field > > + * to a destination header field. Tag, mark or metadata can also > > + * be used as a source/destination to allow saving/overwriting > > + * an arbituary header field with a user-specified value. > > + */ > > +struct rte_flow_action_copy_item { > > + struct rte_flow_action_copy_data dst; > > + struct rte_flow_action_copy_data src; > > + uint32_t width; >=20 > Why use 32 bit register? Again, to make API as generic as possible in case there will be a PMD drive= r that can copy a huge chunk of a packet into the another place of this packe= t. What is your opinion on that? >=20 > > +}; > > + > > /* Mbuf dynamic field offset for metadata. */ > > extern int32_t rte_flow_dynf_metadata_offs; > > > > -- > > 2.24.1 >=20 > Best, > Ori