From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; 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 <B5ffdb7b40002>; 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 <orika@nvidia.com>
To: Alexander Kozyrev <akozyrev@nvidia.com>, "dev@dpdk.org" <dev@dpdk.org>
CC: Slava Ovsiienko <viacheslavo@nvidia.com>, NBU-Contact-Thomas Monjalon
<thomas@monjalon.net>, "ferruh.yigit@intel.com" <ferruh.yigit@intel.com>,
"andrew.rybchenko@oktetlabs.ru" <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: <DM6PR12MB4987F17418EFC9CA3AC7AA43D6AA0@DM6PR12MB4987.namprd12.prod.outlook.com>
References: <20210108063234.7679-1-akozyrev@nvidia.com>
<DM6PR12MB49874C33F76E674CA45A817BD6AC0@DM6PR12MB4987.namprd12.prod.outlook.com>
<BN7PR12MB270710E46F3A21A6782AD312AFAA0@BN7PR12MB2707.namprd12.prod.outlook.com>
In-Reply-To: <BN7PR12MB270710E46F3A21A6782AD312AFAA0@BN7PR12MB2707.namprd12.prod.outlook.com>
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: <DM6PR12MB4297673AE814FEC245A763D2D6AA0@DM6PR12MB4297.namprd12.prod.outlook.com>
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 <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>
Hi,
> -----Original Message-----
> From: Alexander Kozyrev <akozyrev@nvidia.com>
> Sent: Tuesday, January 12, 2021 4:16 PM
> To: Ori Kam <orika@nvidia.com>; dev@dpdk.org
> Cc: Slava Ovsiienko <viacheslavo@nvidia.com>; NBU-Contact-Thomas Monjalon
> <thomas@monjalon.net>; ferruh.yigit@intel.com;
> andrew.rybchenko@oktetlabs.ru
> Subject: RE: [PATCH] ethdev: introduce generic copy rte flow action
>=20
> > From: Ori Kam <orika@nvidia.com> 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 <akozyrev@nvidia.com>
> > > 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 <akozyrev@nvidia.com>
> > > ---
> > > 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