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 60C78A04B5; Tue, 12 Jan 2021 18:20:07 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1500F140E97; Tue, 12 Jan 2021 18:20:07 +0100 (CET) Received: from nat-hk.nvidia.com (nat-hk.nvidia.com [203.18.50.4]) by mails.dpdk.org (Postfix) with ESMTP id 03FB4140E96 for ; Tue, 12 Jan 2021 18:20:04 +0100 (CET) Received: from HKMAIL101.nvidia.com (Not Verified[10.18.92.9]) by nat-hk.nvidia.com (using TLS: TLSv1.2, AES256-SHA) id ; Wed, 13 Jan 2021 01:20:03 +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 17:20:01 +0000 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (104.47.70.101) 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 17:20:01 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kbsFVmjKVVlM7C2iL5+X9NiPvn89MZ21MEARsThbJrmpOIaEEdR/MX1nPfSjRiK7hckaa5HYNQP9ebrXzI0BAW3OfCgWA/3gDlgj7lkMzESHU/zkzeKJpkb6zeGvPbBKVSX/LnxBIbChUbp+ehd0kexG6HVJZO1JDuXblkmsbdZu1C7rZM7O5kdSj/Ez05w07XOoHG5A5shl0N99pqdSnkSkxWMsH4w29CXghe4irbBP3y147BaaGK1P75G/eR8oq7N5p55qmiSGFk6Ua5SlBA1uOIMFyFezS1kSXZ+yqntIf8Q+K7y7H6oKnQEilEBjDwvh5tUo6sTTDtCHsYhyLg== 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=BxaKHYJJVJ69xQJ1+UNeCsHap14PuoOfkeSsFgeU0JI=; b=D1Ff4tLazdTFfZ7BCxYazlv3F2Pym4yKcDDsJAHLFzv3Pd2VTNuWC9G6jQi5m8FmpognjsaWTj1srTaKgrPukzMuEYzUvzJejzQGQMKg64hyhKwEOu/OEvzD1VqyPZnECC7xLvl68upPoZ2DWeJoP3nQ+jVNdaPLnyTekhXCQFTVQB6HBFz1HetQsOG4bB5JR3wSB7rrBGGpAq5CHaEOJNf8fqsTaOdgzs8h6Hdu7FKoz9tKfjMFL8XUUgDiX92jgJzB9hiOxL8hQ8iccWTMEFqFHPnpHIoupN6jbB/QeC8VM7cKi3AICZa8VB10WU20qpi0tgvUbkk9RjDsR45pig== 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 BN8PR12MB3060.namprd12.prod.outlook.com (2603:10b6:408:4a::30) 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 17:19:59 +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 17:19:58 +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+wgAAQsYCAAAXVAIAAIsfA Date: Tue, 12 Jan 2021 17:19:58 +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: 4e88d5e5-d9dc-4278-8e20-08d8b71e49d5 x-ms-traffictypediagnostic: BN8PR12MB3060: 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: IrYSUujMTOk2aYGe6O6iUHY/8NN45FEUhl/p9AU7slW72mjDGyOoeqib3l4F6fG/h+kuVHocMrBlg1tMZcaxhW7hnYMgxbYJb5jydxjfMUBC/Uf/ISrHzRN2SsHon+ybzzZpJBbt24PZMRbuvWaYfiBqqnP9DAZUQDG4coG5EtQ0zC9IQGSmuAW6YXiXWPIqNTDBiH52TJWs61I8p+nQXu5Kg3caGLM01gs5ODgy7mnkQc6Ul9EfB7xA6Z05G1Xeck0sIX2Ug2IdGxfv0trh/yxRJQ3e46gqRcBVSH4nSDZvzEzCxN5ZyXaeDjMUPryJZc32wx/dRCG9Y+Tc+lRlSDtMxxdVZbPGrfuasDkPfguY+lw+bl4AbJcXlG3+a08bJ7XwdACPAMMejgGIbLJ3v1uN3kluCqsxkBtdP5vlBo8U9dOadl6AbgdCWBRukWp9l2yUlS1WPMIFigsG8BHdTDWfVZiWWASNmTOUFq1HziCBUU7g69i8vCHhxCMKg/xnjcJ1IVKTNkLwJNFgnaaywQ== 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)(136003)(396003)(366004)(39860400002)(346002)(376002)(30864003)(86362001)(64756008)(478600001)(2906002)(5660300002)(66556008)(83380400001)(8936002)(52536014)(55016002)(71200400001)(4326008)(53546011)(6506007)(76116006)(66446008)(8676002)(9686003)(33656002)(66946007)(45080400002)(186003)(110136005)(7696005)(316002)(54906003)(966005)(66476007)(41533002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?uZGKuWFL35jC3n1Qxcbs8bmnl9gINlTYSj1Qoy8s/EB7juByw9Z2fI2aCbrT?= =?us-ascii?Q?j+aqcgULhOCaRVgyDSXNrFlUy5oE6joHz9sJjBYbEbBsRwPUrLqJbG8bVynr?= =?us-ascii?Q?Z9uobe9cpT4AdQCEc+wRpHk515SpnAvdlya9stRrS/ZYwCLYswj48UmVEn9v?= =?us-ascii?Q?KfwdqvNwWKYDRFePQ6wVRM5tOYPObX3Hkkf8XeSB9MEUF7t7Nz10o8fVc2iR?= =?us-ascii?Q?mNY9y8/N+Rk+/4w1STL3pc/EFrK2TCSJ2ACetwLisEqvCm/II/F8eCpGswla?= =?us-ascii?Q?uKFfk8sboZTDE6iwBETB0ddv1ux25/lSEpFd3L7+dmFejjT1VCgzIponLdlR?= =?us-ascii?Q?oUTrZrxzPybQ31sqdhnLdDH+TbHZ0DsVbxGjHgnle03UpBW9Xxu6GoTYtJ8p?= =?us-ascii?Q?PgB6pgzeZO/ylXYPGvcnAYjKPPju9eGftwpH+kHo4EBtkB/3PD1dUAlmGaRV?= =?us-ascii?Q?a0QCItZeXAZ82tHxIFEzujo4m5uG0k5LTknLvpiL22pZ98LlBU4dGr8tzBv/?= =?us-ascii?Q?cTvYQlf3gIU9VNOJsXghKGaVCdF4Ax0mXkMDqs/n0jOilIXzOiqiId88rIyN?= =?us-ascii?Q?xNrIzNo0Rc3UYeHD//bbEBszFT8Wb8yHSw8yNQ2v3oDZq7V6j+4BHu7tcGBR?= =?us-ascii?Q?oO+e6xqmgjBr2prWGjpaYci//0A2E8CcKRVp/sNgTwk7QtjM+buo1SElLl2E?= =?us-ascii?Q?6pZlZ0OMgsly13N3hqiDkaH8oycHnScO/TWAtRrLg95V23gvjdf/vagDmjmI?= =?us-ascii?Q?p8iGvHh1BP1K9WSXqg6IY/UswpN282E0bM9j2bURe1nGAnpEVjwqLE641IhT?= =?us-ascii?Q?RWYzhpXi/9HNITcAt+9xLkaUUDgamgOCCJHePngnQa9gmEuag22I/Egk+fwZ?= =?us-ascii?Q?vbcrCHxkOS54lj3a4hqNRoUKU4LEKjt0HqisiLF5l/B+CcLlCK4p3bVvgoGu?= =?us-ascii?Q?KT/chC0JAtlS+s7fOovPyRhln+YNJiKzJcRqqlZnfaGQzlBJGt9V46FB2uO4?= =?us-ascii?Q?N0BEiBYr+gVoOIoiV2h8L51Y/cqHAcTQO3w2HISUIJ21UiI=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: 4e88d5e5-d9dc-4278-8e20-08d8b71e49d5 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2021 17:19:58.7100 (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: 5jjqlqWOsJsT3NZGkg31efPdSKexkQdPacmrnjEDAawV0A4QPln3rcaReqqbu8CfrPxD50wC6eYHmd2ZgebXuA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR12MB3060 X-OriginatorOrg: Nvidia.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1610472003; bh=BxaKHYJJVJ69xQJ1+UNeCsHap14PuoOfkeSsFgeU0JI=; 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=MC6YJyQaZkodKeNkFjsn0brBK5hC7Tao5iUhHyWTeVcXtW6lLs2osgtuotsgdgAzD Xb8boWJvWLyxkIFcIE7mTs9jt3Nl6xXVES6Qc343r6X1hbxlasyGPdZ+wNFn8y48Ay 2CdwQqYUX/UScDIKQvIVRpRwbdnT2kR7k0yopXSELmcmZbbhvEWE3gw54kD2gW9hVk kKUzTGTsWrsqRg0g9vPu7Stu68MzDc4Akfe5hxnFheoU9c1U5Hrh4tolDjuzXOg+Of mvCXqrhfz/DcRZh6v5VuNOpl00hNFq3nIQjqg4bOVnkkvQIasVqMQnN2OPwTN2RboE bJkkPVjS3IO7Q== 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 onTuesday, January 12, 2021 4:53 PM > > To: Alexander Kozyrev ; 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 > > > > 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 > > > > > > > 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. > > > > > > > > -----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 arbitrar= y > > > > > 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 packe= t > > > > > 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 ca= n > > > > > 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 peop= le it > will > > > be > > > > best > > > > if it will appear in the commit log, at least the advantages to thi= s > > > > 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 valu= es) > > > > > +can be used as both source and destination items as set by ``ite= m``. > > > > > + > > > > > > > > For tag I think you should also use the index right? > > > Right, index is here to access any element in the tag array in additi= on to > > > outermost or any inner packet header fields. Will specify explicitly = in the doc. > > > > > > > > +Inner packet header fields can be accessed using the ``index`` a= nd > > > > > +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 mo= st? > > > > 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. > > > > > Not necessary, like I said please look at the RSS, 0 can mean the inner= most. > > > > > > What happens if we want to copy between different sizes? > > > > for example copy IPV6 src to number of tags? I assume we will be us= ing > > 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. > > > > > > > > + > > > > > +.. _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, > > > > > +}; > > > > > > > > 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? > > > > > Yes better, > > Or rte_flow_copy_item_id? > > > On second thought I think a better name should be: > rte_flow_field_id - I removed the copy since we may use it in other acti= ons > for example set/add Then I would prefer sticking to the original rte_flow_item_id naming. It allows room for anyone to use it as a general enum and incrorporates tag= /metadata and other future extensions, not just packet fields. > > > > > + > > > > > +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 bit. > > > > 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 w= ith > > > 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 th= e offset > to > > > the > > > length of a selected packet field only? Index is 32 bit for the same = field in > RSS. > > > > > 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= driver > > > that can copy a huge chunk of a packet into the another place of this= packet. > > > What is your opinion on that? > > > > > Nice thinking, > > > > > > > > > > > +}; > > > > > + > > > > > /* Mbuf dynamic field offset for metadata. */ > > > > > extern int32_t rte_flow_dynf_metadata_offs; > > > > > > > > > > -- > > > > > 2.24.1 > > > > > > > > Best, > > > > Ori