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 DE99EA04B5; Tue, 12 Jan 2021 15:52:40 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9A9C2140DE9; Tue, 12 Jan 2021 15:52:40 +0100 (CET) Received: from nat-hk.nvidia.com (nat-hk.nvidia.com [203.18.50.4]) by mails.dpdk.org (Postfix) with ESMTP id A4441140DE7 for ; Tue, 12 Jan 2021 15:52:38 +0100 (CET) Received: from HKMAIL101.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:52:36 +0800 Received: from HKMAIL104.nvidia.com (10.18.16.13) by HKMAIL101.nvidia.com (10.18.16.10) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 12 Jan 2021 14:52:35 +0000 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (104.47.56.169) by HKMAIL104.nvidia.com (10.18.16.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 12 Jan 2021 14:52:35 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hGrXCcHEnHvsQmSasu0Jsu7g6fF3okP0RuNETxGrzZ5JxAL7ZzjR/ywILEBp5Lo1RBO6mvUAXNKj0MsYzGoUn6JID8QhVxeZhqHSydvnGMN87dBGySJbhoIgHDPQhcl934eMNB1SmjYjgoKfw9+ZhQhWVL7AN7OBKykPJI28ljVlLOACS2x5ZKqkhrPI3aR8lhXeK85gqqpGf+6CiPMFKUqFQoSRXqT/Ugx4M9Pe5cO3a2FGS7VauE2Q5ERmPVaZT+GIsw1VwYKt+hGSJCen2KRmt/R9UIjo9PlECYlrXxdUGuC8RQiq2ruv2v4pIiBoLYXOcCZla3vDBaoo3wDYfA== 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=XyjC2rsq9An5mnnK6SBKjzKabv9BIoXqPRHhof5D8yk=; b=a8AYDXtkgbGRGKRwbiXTziJ/brqRQARt1lTxnmLkMokfZN5mOetNncIKxyNMVJDc8I3I43rBdV82pgiX4lHysZQkISsyP7cDncarpa3gbZC2FevgKLvFITrdP+uJ6Aq0SMdgzLKUE8B9Sfxvuim3gtUseX/F/yQHGCt+tQVY4NH/RYNP1Hm+XcIrMk2LM9zeF9YNePSVB5v+YS3P1XRRQX0mbM0c+B1WwJT6L+A+Syl0rlX4eypd5YDc2UqarEKO/2k0a6wcBI6VwxZlKPcEC8Tn7LDhEbJujnFjjikb87wYfTzDnsANLka9ZqXPbwZqWewRlJNlMhzVi2HEq6tCiw== 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 DM6PR12MB4987.namprd12.prod.outlook.com (2603:10b6:5:163::31) by DM6PR12MB4297.namprd12.prod.outlook.com (2603:10b6:5:211::20) 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:52:33 +0000 Received: from DM6PR12MB4987.namprd12.prod.outlook.com ([fe80::e1e4:bf73:a753:2665]) by DM6PR12MB4987.namprd12.prod.outlook.com ([fe80::e1e4:bf73:a753:2665%4]) with mapi id 15.20.3742.012; Tue, 12 Jan 2021 14:52:33 +0000 From: Ori Kam To: Alexander Kozyrev , "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: AQHW5YgR+7Ov3GfAIkW0PNLie6o6Jqogen4QgAOVOYCAAAgosA== Date: Tue, 12 Jan 2021 14:52: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: [147.236.145.126] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 91601687-518d-49d5-eca5-08d8b709b17b x-ms-traffictypediagnostic: DM6PR12MB4297: 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: HP4OsLGevW27d6KlNzitAf8Ob6Kz5NsoWczwjJQ5zgdgncrqRD41gr6e355pcYbI0z+X/Jvj3Cvw/yVeGoHXVQ6TqXC9rIzJg90YNA2uH3qAWvG6xcD1e6/8zqyn+lOef/Hu6nT2PQdDYL+UikSWGcIpSNhMiAclIpmxftpQQqcV4f6rqeZDIs5FTtK5Ljo+Qtxn7DgrmMaDFgxg5haV9S/Bkespc26bqFDhrow0BBIijMxminXtZKiKmBiSulRVYN/m2HdKbFN3gU8xdJsfWZZzPfbcWCP1qPOEeazmPz2QZopFGc8jCG4bmKBRSXkELOmOAcH8w67IXO85tyKHcABixRf252wf43UES1g0FfyOSW2FNg2ikV1jicmmKBE0sZMSdSvvv3aYiY1ZZNHrLy/a4WWcIqrBewCytSb1Pzejsv/+sAppZZaRYTFlwMdk8lXvH4yZhxSuY1DRpPZpD1aUqld0xfWQGEPjfdh6kd3wmMmxKsy8k+7OKg+DqAcZs9Iv/se9Mo/7Qagwi7fyGg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR12MB4987.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(136003)(376002)(396003)(346002)(366004)(54906003)(966005)(8676002)(478600001)(8936002)(45080400002)(7696005)(4326008)(71200400001)(186003)(2906002)(26005)(5660300002)(52536014)(86362001)(110136005)(6506007)(33656002)(66446008)(53546011)(83380400001)(316002)(9686003)(66946007)(64756008)(66556008)(66476007)(76116006)(55016002)(41533002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?ED0ZruMUbTp6ctmt8/hxxhBKFBUC32sLWG/IEPLt3vkGhrWtCPGR0Aa/n8a3?= =?us-ascii?Q?mUinLPNZmwI91RzD0Y2PSI7uNc2/l6En9pvujcUEbD3ABpyXkclgfrgEHFjv?= =?us-ascii?Q?/cVpi/ydw+pO940cGAw0PnIVB5AQmGFXKBpl6lqtwiVUt6rfPxOeQ+FdOQXo?= =?us-ascii?Q?2qpZ0dzi2HOSMZ8pdqdfhUuiNprgVov6DFZ05/WDiaLJ6BVAg/CJiEnolDSa?= =?us-ascii?Q?QJSP64RuZTCXFOd+9VNQ2A8sZIbSXOmTWxKrfRb8vpSHXis2fGNTAOcRsw5U?= =?us-ascii?Q?rthleMMEaT5U4rUtPGXg0JlyQs3gdgf+wvORQEtQOaJsQZsxKVsxB0gdPsG1?= =?us-ascii?Q?6qXNRkmtpClgnD/frhaWoVWVVFy85nBCtVCt0KUYjBFchmxaCJBCy6eWba/b?= =?us-ascii?Q?C+9+JBzYuNYD6YkuwEULMBcBDL/h/sZ6yYyxvDDa8dgq4OyTe2RwXXyXiLLy?= =?us-ascii?Q?w1TZi0DdvSCYOv+AID7XZuxkf63tPKkRZnKGh+w7kkjVhb4LPh3fTdG8+ist?= =?us-ascii?Q?fh5e0tBFO6VTetAcdT6a7Ya6rFPy+IzD9JbECZtSl3WsZ4EBGqXJKin1TJfx?= =?us-ascii?Q?APfwexYZ1b5Tpx5RfoOaVR97KMapwMyk3EHy/pmXhz1eMl7b5jU+/42cAfto?= =?us-ascii?Q?/HYdjamt40rg8PyhBH87S6aXwKehb+TSiJelW3udQ5rmAty60UAJYlQPT3Td?= =?us-ascii?Q?mkMQ3OJn7K2khRHCy1cjwh4niayM5auM0iIO1SovVNZJ+aNBRia8NPimPA0H?= =?us-ascii?Q?kH8Tson6ulLjnWZR8M7YtjU1feas/iUFXkB6o8wKi5r+Egcg2SBo4bE7NVLS?= =?us-ascii?Q?AF/OoiSg0vcotk62+SAqYcxfAIaK+LqUNbBOu3YMX3w8lTO+t3cGkcAbvQMx?= =?us-ascii?Q?zvbaqhAzuIVQQkZlAroLomp452wHOQoF0VZGv99YBCzJZH84Vxt7EWoSpISL?= =?us-ascii?Q?oJuIHTdUPFf+fqd5CLmUoCbiJ0oZT2rCXNCsjNakvDvgmHNvoZLLZleaCEmQ?= =?us-ascii?Q?N5uc?= 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: DM6PR12MB4987.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 91601687-518d-49d5-eca5-08d8b709b17b X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2021 14:52:33.1973 (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: kgwgFROkW+EOLTjMh79AuWniR0NdAQYFXj0MrJET3qy84X0t9bcv4aXonf2EC1Bx5XKbkEBLFc3MCShv7mOGpA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4297 X-OriginatorOrg: Nvidia.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1610463156; bh=XyjC2rsq9An5mnnK6SBKjzKabv9BIoXqPRHhof5D8yk=; 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=fLzhzJnFXi4YgdjRULPRV43I/XGNhAF/YBKhVHOfdhlGkrLjHnetU0VPDY6LLtLh3 TRs4YanT98v4Bf3WNW7rJiEj95K1PDFWQd6SvOqpyNLo+8689L3O8iQYv/580voQzb cv5hznc6PLGgXsKA52AtNw5aTi8yDRVqkBtS016tORUUmnOCqoCoLs0E0AEMEuZySn uZ0YLSnlEIREjYfDFfLpHZTysk5QbmJwYItgahFnUGVfLvv2kNzaUrAZ7GZ1vXlzin tD3KZvHkM6bFnItDhqbkwO0vrCyOtXqLUhydWAOlSVEwKSiXp2I8SP8rAUGlPHFJrg F2y6CCYBRVTYA== 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" Hi, > -----Original Message----- > From: Alexander Kozyrev > Sent: Tuesday, January 12, 2021 4:16 PM > To: Ori Kam ; dev@dpdk.org > Cc: Slava Ovsiienko ; NBU-Contact-Thomas Monjalon > ; ferruh.yigit@intel.com; > andrew.rybchenko@oktetlabs.ru > Subject: RE: [PATCH] ethdev: introduce generic copy rte flow action >=20 > > From: Ori Kam on Sunday, January 10, 2021 3:01 > > Hi Alexander, > > > > I guess that the test-pmd part will be available later right? > Yes, please take a look at v2 version for testpmd implementation. >=20 > > > -----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. > > > > > > > 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 i= t 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. >=20 > > > RFC: > > > > > https://nam11.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fpatc= hes. > > 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``. > > > + > > > > 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 t= o > outermost or any inner packet header fields. Will specify explicitly in t= he doc. >=20 > > > +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= . > > > > 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. >=20 Not necessary, like I said please look at the RSS, 0 can mean the inner mos= t. > > 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 = offset > > and > > split the copy command to number of actions right? > That is the correct understanding. We can utilize 4 copy_item actions in = this > case to > copy 32-bits of an IPv6 SRC at the time (specifying different offsets) to= 4 > different Tag fields. >=20 > > > + > > > +.. _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_flo= w.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_flo= w.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, > > > +}; > > > > I don't think this name is good since it not rte_flow_item this is just= internal > > enumeration > > for this action. > Will rename to rte_flow_action_copy_item_id in v3? Is this ok? >=20 Yes better, Or rte_flow_copy_item_id? > > > + > > > +struct rte_flow_action_copy_data { > > > + enum rte_flow_item_id item; > > > + uint32_t index; > > > + uint32_t offset; > > > > Why use 32 bits? Since this copy only one register with max len of 32 b= it. > > The max offset can 31? Same for the index. > This extends the flexibility of the copy API. This way you can modify any= place > in a packet as you desire by specifying RTE_FLOW_ITEM_NONE to start with > the > 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 of= fset to > the > length of a selected packet field only? Index is 32 bit for the same fiel= d in RSS. >=20 Nice idea but then I would add ITEM_OFFSET or something around this name, I don't think NONE is a valid value. > > > +}; > > > + > > > +/** > > > + * 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; > > > > Why use 32 bit register? > Again, to make API as generic as possible in case there will be a PMD dri= ver > that can copy a huge chunk of a packet into the another place of this pac= ket. > What is your opinion on that? >=20 Nice thinking, > > > > > +}; > > > + > > > /* Mbuf dynamic field offset for metadata. */ > > > extern int32_t rte_flow_dynf_metadata_offs; > > > > > > -- > > > 2.24.1 > > > > Best, > > Ori