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 175D7A04B5; Tue, 12 Jan 2021 16:13:32 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 92C3B140E0D; Tue, 12 Jan 2021 16:13:31 +0100 (CET) Received: from hqnvemgate25.nvidia.com (hqnvemgate25.nvidia.com [216.228.121.64]) by mails.dpdk.org (Postfix) with ESMTP id EB655140E0C for ; Tue, 12 Jan 2021 16:13:29 +0100 (CET) Received: from hqmail.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate25.nvidia.com (using TLS: TLSv1.2, AES256-SHA) id ; Tue, 12 Jan 2021 07:13:29 -0800 Received: from HQMAIL101.nvidia.com (172.20.187.10) by HQMAIL109.nvidia.com (172.20.187.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 12 Jan 2021 15:13:27 +0000 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.176) by HQMAIL101.nvidia.com (172.20.187.10) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 12 Jan 2021 15:13:28 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R1Y9Ei0lYvFth6OgLcKU2i9tOc5WXZI8qubMn+aJ7K7daTiAfOXLOz7tiSoRzHs8oXWTlfyTeo8wf4qGlbSqGvdVfy/awZq26ziVVCP9sg/ODYMm9Nj6HD/eICpSyT8m2BuXgPIkA8MCUdNODNspE3x8RChKq8MNiYNm+/ObjjVBqPpNdBGine3joJMI5J8Q71/TmZjwf1cwmyDiesdqP5ZCFD+sBWfresyom8AbtDSBYyiFbzmCr1nACwOzdptslYbJy/n9kFNG5fRJ1HZ1j+wnoogFkwAE/H3WC7gw9C6u2oXZv5tCUvss0iZg4XBqoRZ4e/HE3P8AXTcOdEE/6w== 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=8Wl57lmgYWOg5+JutdlsieeJ3r1FgFuxG9hHmtOxORg=; b=HvZPRCcEVfWqUK203fld6lHNXg/90TCgsUGtIMFsccBTLPTJiGaBuV4ur78m4IaOUiJxYCknniaaZD6ib1czSaFxZJM2HLPXnsj/sXFC2wJJyIZdaiUq3EcXIrF135E472AHpuasUFS+DCp2ry3wvwSkxzmOY5jeKmlmH8Bpw4YsCoayM7Brzuk6b7jPUHRrNxIaGdtNaAGyvVzEdHGj9xsps1H+9x66s+6bwxigVKfKzeaKX9FVRW6TtciyFUg4tmD/p3VA2m8ZFGGFRtLDyC2PNL3bcB6qTQrBqpVfzyayh5kz3IxZHw6xDaS+OMI3/LBmtRff7E0UgMeVlASIVw== 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 DM6PR12MB4075.namprd12.prod.outlook.com (2603:10b6:5:21d::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6; Tue, 12 Jan 2021 15:13:26 +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 15:13:26 +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+7Ov3GfAIkW0PNLie6o6Jqogen4QgAOVOYCAAAgosIAABuOw Date: Tue, 12 Jan 2021 15:13:26 +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: c0997e3e-ca7f-47d5-f0f1-08d8b70c9c52 x-ms-traffictypediagnostic: DM6PR12MB4075: 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: XPTZAEDxFbgYLSfyRFeedEE6z4Pr4s1CHL+PcFc8Ogx3JolrAWC9uWItBaB2GRPAKn/luXHNNei6BhK6JcWYGZFjW/x0ODQPfEo/GdrG71m+Tg5w7k5yizQYsIQEvQmGEYV225pQWxsYWi9Hsm3pQXet1+Al10Sz+6mp4HQ3SRNrGLGeHoX/HXgBUP++0hvGYErvM/gbUzEEkAb4NEX/0SA+OB8VkaKMVKEj7X3ub+8y4xaHhFONBoii8xzW31j9Yig7OUgLU8IXTKVkN3kjZQlDnX+1Fo4NTMqT724HTVltzTcrxrbCQ5okDu3Efawm1VohWJIToRaUJ49J08TMs0wbZ+/PcyAqpDtZXwCR3rGazM1G+IZGa80T7LCE19IbQdcCEYDZEAvoV/5YeWFibULeaSHsDIb/JNvsXLRvWdWr9M0WaO6rZw4JAac8CHOQxlrMwQtlMLc7aZ43g1nrXoddQOD8NfM+LE369MTn0wUAAtW7dd8w+9Jw7z7Cg5Z91gcnuJ86WUIBH3zLnFXh+g== 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)(346002)(376002)(136003)(396003)(366004)(39860400002)(71200400001)(8676002)(2940100002)(66946007)(30864003)(478600001)(54906003)(2906002)(66556008)(966005)(55016002)(53546011)(76116006)(9686003)(26005)(7696005)(8936002)(64756008)(86362001)(316002)(45080400002)(83380400001)(186003)(4326008)(110136005)(66476007)(66446008)(6506007)(5660300002)(52536014)(33656002)(41533002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?IUPxpg564bt4tC0JJZ1QhTM3pZD0azaTgkQE7tKGxvd4OSgtvkCT43lRynHi?= =?us-ascii?Q?aHn1g/7R0lnG5Asd407wu0PWtBjkI/V4ufG9V9Po/oX4DmXtacIpiHHZM/6b?= =?us-ascii?Q?z/eRZuAllEH7pudnrfhC63EV3Dpz4n2BUhgFBrBRESDgV842knTWHGUL+LIJ?= =?us-ascii?Q?nrzDD2ZiMSxhYXTXo8iW9bouIHpLZyhT2QsVLoXEHIEwddXwgOx20vP1/7i2?= =?us-ascii?Q?bpiLiREgFkl2eB4bUMd7boZHgMSrGvm6pNsIFXFPzpAG/GXkpJyTL+KWKded?= =?us-ascii?Q?s2Z6xlAISQK0Y9FfjrQnUvgB8OK8q4v+DgNCW6Rcig3cWPQzlraCfqGPz6iq?= =?us-ascii?Q?CnXZBJQfBqc8o0eW5gH5Seh+hGpzwmV+pf+B4AVNkU3PK5YRSLTDKnMaNXRX?= =?us-ascii?Q?MCDuAanHHwi+RsaefnoUo2clZybVkZjTv0toBF5yQbnSEdtf3X4LcxMcOm/0?= =?us-ascii?Q?b9TDJBTlPYqBi25JiNXRzrKQ4h7gl5NUizoL1NO+IxXQJFIwZuXCGuUdIhBj?= =?us-ascii?Q?BmWFaHxq2PkP7JReaH6r1w9+JP2Ox8pkHxfiyeFuqnRnqIdQvqosKhzpGVhX?= =?us-ascii?Q?1M9aK+jn4S4Oh5QvbLlaLTBjYaV8dVghC4klnT4x0oJpQ1LVL23e4wQaQQ8j?= =?us-ascii?Q?glHjB0ZFVqdqhGEkn1qVYOKUerS9xeJO8v6UDZMtRyPvTDkbBPRqpegjbS1a?= =?us-ascii?Q?ZEElUcrEhma27ikKN4ORoRqhV7CkPnuDN2TuJndUopqVkiUW7H9kUEsk6ANT?= =?us-ascii?Q?CvWdnmz7N2DmwJPtlDKGQZPif+wuXA/7T9triJ3mX8j3cQjVPZMk33PMkVQ4?= =?us-ascii?Q?CkPpE6BtRGsNplCGe10+kVSpFl/Ivl9do+huwV3NDy/V5se7IQLA1zAXdbeZ?= =?us-ascii?Q?R6HUqIbYrw4B1JK9aA8LE+NdFPM9ST+u/zIQb1hQ7g0oEG88RayrYKq5JbVp?= =?us-ascii?Q?rWlTzalQ5cXISFiNr6HWHdl0T7d9vLAFOPeNLO+x0WMBVbPuqsQ0CL3GgI7A?= =?us-ascii?Q?YB+v?= 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: c0997e3e-ca7f-47d5-f0f1-08d8b70c9c52 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2021 15:13:26.1458 (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: yuD6sUTum34iUDEDIVF9jv4jVk/KLkXfT3tbXO4sT7CuujnfkZz4mYPF0hn1AR2vs088PWov+TuGBFhp/h+eXQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4075 X-OriginatorOrg: Nvidia.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1610464409; bh=8Wl57lmgYWOg5+JutdlsieeJ3r1FgFuxG9hHmtOxORg=; 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=On+1DyR2lVnLfOpHzlGR5V90U8rKcWXGy9rccyFMZvx9I4hsF+87VIjNfLt1Ra26M QDtxcKfkn0+RhEohYaRP5o+3crSqNqzVuKHP7b6NXRg9/2jDZ3XIowRgRBuDJh3XHa lZq0K0sWeleon8ZYk4LJThcpH/NdGz1ZtAd8Hh+t665nYnm3bzfwkHD5QMaIzlf/wh OyLTF97T2ghSybxVi7Hzp9u4sP/HOqOmSjLyw/sWTdRBLd9+rzdol03JXrJOw8sI7I Y8GQt5DiMOQA6SimRUskjCQgJ2li992qmk8AgkjpVIyTo7eeNQygbyUdPG2P0fCuGC vJ7e6aAxz0mWA== 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: Ori Kam > Sent: Tuesday, 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 >=20 > Hi, >=20 > > -----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 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= 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 b= y > > > > ``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= 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 it= em. > > > > > > 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. > > > Not necessary, like I said please look at the RSS, 0 can mean the inner m= ost. >=20 > > > What happens if we want to copy between different sizes? > > > for example copy IPV6 src to number of tags? I assume we will be usin= g > offset > > > and > > > split the copy command to number of actions right? > > That is the correct understanding. We can utilize 4 copy_item actions i= n 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_f= low.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_f= low.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 ju= st 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? >=20 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 action= s for example set/add > > > > + > > > > +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 a= ny place > > in a packet as you desire by specifying RTE_FLOW_ITEM_NONE to start wit= h > > the > > beginning of a packet and choosing a particular offset value to point i= n 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 = offset to > > the > > length of a selected packet field only? Index is 32 bit for the same fi= eld 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. >=20 > > > > +}; > > > > + > > > > +/** > > > > + * 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 d= river > > that can copy a huge chunk of a packet into the another place of this p= acket. > > What is your opinion on that? > > > Nice thinking, >=20 > > > > > > > +}; > > > > + > > > > /* Mbuf dynamic field offset for metadata. */ > > > > extern int32_t rte_flow_dynf_metadata_offs; > > > > > > > > -- > > > > 2.24.1 > > > > > > Best, > > > Ori