From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (xvm-189-124.dc0.ghst.net [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 35370A0524; Thu, 7 Jan 2021 15:17:34 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7CAC9140F87; Thu, 7 Jan 2021 15:17:33 +0100 (CET) Received: from nat-hk.nvidia.com (nat-hk.nvidia.com [203.18.50.4]) by mails.dpdk.org (Postfix) with ESMTP id 88FE1140F85 for ; Thu, 7 Jan 2021 15:17:31 +0100 (CET) Received: from HKMAIL102.nvidia.com (Not Verified[10.18.92.9]) by nat-hk.nvidia.com (using TLS: TLSv1.2, AES256-SHA) id ; Thu, 07 Jan 2021 22:17:30 +0800 Received: from HKMAIL103.nvidia.com (10.18.16.12) by HKMAIL102.nvidia.com (10.18.16.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 7 Jan 2021 14:17:26 +0000 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.172) by HKMAIL103.nvidia.com (10.18.16.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 7 Jan 2021 14:17:25 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eqtq5vLJWVOk3NUxjrzAd2EtTbIJntMuP6N42SeTVXdC18jPID58x58T2vVqTAFZRGe+3nwb3mniraAFReP+bEgEnbFvGg1UBxNEwC1ZluVyilmm7GZLkKy7Dkv4jnx/9HoI/OpbgOaHk6Ri/tM0y3B3Uzldg9cJSGIOlPJrj2MQc6IaxSG8NSD8MtytYco3jNo3t6EYwF0u8jarnv+maTkl6mQ5BhJAdcbEHHjU3cNpPmUqxcmMLRamr9tXoOl6zMzMRf54/2RIdibp8icTVNYjaRCkS7vnN1ttQ/rIkq/Jgs+ndsYP0hY6EujGyzkF6a36HypMFZkA51ulAo9K2Q== 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=YTxqO/cc+PrdxhatSQJILh2CCzGWuSe5e5+uXw7aXq8=; b=cm2nhmCZA9QXM9QEIHCkWe11EwLgMESHG9FxCf0Bt3c/9G9EQWhvPDw++y1P6IBpPmCvfzQQ/dL14itkZQRvtMK0611wsSSo7qTFGT/j+6XttzgHDL+x/HJ5q/vkKlYQApNeS+7sPWEBlcE0gtsKbd5iU+lPcFDqTKtphJ8gTeSutAiPRdyPIDnmX19If0VCU2v+KBqRRTyL6N5D+j5pNCosHTOiFCYFeQqQpmjIhOgzlTCGPbZcc1YLpG97CmY0uh77w7BLkIG3QTKaQIvhKimGAg2ioh1XK95Gm1a/K2Y0Aeq39rWqxHr/KmhwB8Lf735uwQv/SdGSDieo5IYyFw== 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 BN6PR1201MB0115.namprd12.prod.outlook.com (2603:10b6:405:59::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6; Thu, 7 Jan 2021 14:17:22 +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.006; Thu, 7 Jan 2021 14:17:22 +0000 From: Alexander Kozyrev To: NBU-Contact-Thomas Monjalon CC: "dev@dpdk.org" , Slava Ovsiienko , Ori Kam , "ferruh.yigit@intel.com" , "andrew.rybchenko@oktetlabs.ru" Thread-Topic: [dpdk-dev] [RFC] ethdev: introduce copy_field rte flow action Thread-Index: AQHW1N2TdPEI29qYiUa+u6muk6TpcaoZtyQAgAKb6PA= Date: Thu, 7 Jan 2021 14:17:22 +0000 Message-ID: References: <20201218013129.25186-1-akozyrev@nvidia.com> <69996023.yYu3UIiVKq@thomas> In-Reply-To: <69996023.yYu3UIiVKq@thomas> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: monjalon.net; dkim=none (message not signed) header.d=none;monjalon.net; dmarc=none action=none header.from=nvidia.com; x-originating-ip: [2607:fea8:e380:d8e0:f5a5:eebe:38ad:c361] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cf941c6d-0fd7-4014-ecfc-08d8b316f379 x-ms-traffictypediagnostic: BN6PR1201MB0115: 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: 8wXBqBzlVe+xQ5M9Oo141o4bcPNeollG+Yhu/P49XkTxS85wIMBQOTgXVeDHUfoFPL6aXURvmQIrRw/8ACYEYY31areIGv5cgtT2y616UH0ssFIaIIX4MG3VKfb+gwHvvU2q7GlHobRsDoLb/OSDU7hNBk57scppSc5Dt4SqkBA1zYcdU0yuGsyD0LmQ5+skRuVDptuM5v+R0nfOgBcIc6nsZeMT2n05kb5JhydM+hXQmPdjlNnu9ZIikYpXAzmJwuV0tcTGEBVvpc7bmIFrPIA2VyeKFQwF3duPSOV/KidNo4aqqwxCNrrW4nI5RVk9b/oDxaO5091I9buW4ZW2BfVjrgAHUB1I0DH3Wsfcr5BUfXyJrsZikvA57IH33dXkCkAKT3P43+gWeC9Qxu/XXpxSvFEjlK8rJ8gtGPpLrvpOwDQG1paJk1vSxN2UBEua 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)(346002)(376002)(396003)(39860400002)(136003)(366004)(55016002)(66556008)(64756008)(66946007)(9686003)(8676002)(86362001)(66446008)(8936002)(76116006)(2906002)(7696005)(54906003)(66476007)(71200400001)(4326008)(83380400001)(6506007)(478600001)(6916009)(5660300002)(186003)(316002)(52536014)(33656002)(21314003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?iW/1qduH4XFEltpGQ6pRrOkQ63+lsu0tQhEhZTZWTDYnX8BQOVlw42hjWece?= =?us-ascii?Q?hDYxtFUJb2sZz0tHC7jPDJ7FZXsgiV66rVKCUErKDHoEs7xZd39BX/95hki4?= =?us-ascii?Q?TGUx0x+CP6abjzxQQMm1ArV++xgCOfBeSo7PNlrLDA05qerfs7k6POPOStwo?= =?us-ascii?Q?GA9NJgRQeRErXBVrC7qJZOxrbN6Uqt30rnLG+f2npoTWIm7On/1Ob1c4U7nJ?= =?us-ascii?Q?6lphggzg9AaaL7O2wr17v1OQee0OeXXW4/02Zt59xk5RQy4bSHmVcYWumR0C?= =?us-ascii?Q?MO7TqA9Sl/GIG3AZpwNiUQ3NcuoqSTR6bYyJVFq9tHbidVz9EPo2fAZku5mc?= =?us-ascii?Q?co/gRCyZq0e6AoqNrTamDPz65aXssVT3WpAvMMownlO4jX4x/nCGPN5tV6Td?= =?us-ascii?Q?dFL5YC29oIWrmrGli4auzw4Wk4dy8oeRtMP6OcT7KKx/nbI5fEwtOCoHWpQU?= =?us-ascii?Q?Tz6LXnkGgYXvhyHzMyxqIyZ0j7rxywdA3U39Q/qpi4usmWTxYhTg/YablwZY?= =?us-ascii?Q?raOe+R3IfNHnquB/G62uC7ZdlBUDk+Y2M+EFv5UW0SIokQGtRcJondD6mj8i?= =?us-ascii?Q?Hb3ra7lJQ5Coxogh0j0GbjWFN45IkdbMcj6J4EhBL6Mc//OgOORrNdtTbGZm?= =?us-ascii?Q?0B1W0FVDNaPcPU2MmTzAqauLTvl4Nwx90LbBj/Ys9IYK/zAXRMsDOkPbIloi?= =?us-ascii?Q?/pBgjPri3F+baG/BOSb01eO3tKHziK/rnggKhZvb/9C2cdeGCSxvIsfRiO27?= =?us-ascii?Q?npy/mg5OLwW5HpVtIQI7LmB+f00fp6sfDbgeB88EXdu9WQQrzdXXMbutSbJA?= =?us-ascii?Q?3mUL5cL9yH+gwMh31kAochQUW4H5wFyg9AEN42r38CB9Emp6J8GYW4erFdP3?= =?us-ascii?Q?Kdy9svcksr+sqWicpkMINSB5RrUZy6hiwfHVZ7V9ROtK7Tls3MQS9FW9oYQF?= =?us-ascii?Q?OzePcnQe5CPW6kw+bvY9lSDgDQpc0lU56cY+3rvJElqq/z/ENWItSDow2dn6?= =?us-ascii?Q?jHIPsfc06Uwx1QdWXESelTrfpie3VzQgjk7PaGiUUfHpan4=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: cf941c6d-0fd7-4014-ecfc-08d8b316f379 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2021 14:17:22.7432 (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: lmbdslpZW6ejHnUYOEggOcaeMNWb3F8nYt62fP3c0qr02EH4R55BgRAKJ8bHSOgltyzKMDFQNqSvEuug0mUgtQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1201MB0115 X-OriginatorOrg: Nvidia.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1610029050; bh=YTxqO/cc+PrdxhatSQJILh2CCzGWuSe5e5+uXw7aXq8=; 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=YcSr1qI73xyOIzLRpPMr2NgaQWrvhrW0NEaXRI2X84dL8l+K4xf5bw703pKjQcr5+ OCC+yNK+Q7uvfKS9TbxdV8zIUE6t7TwnMSCYAOZfYQ/ETN9SIGgcxCawpSamHbWynV ETKVUhhtIqKBcaCJ+3+4WqNexRfKLqS/teAtWXlCjIeuHIFaHMYIWIA1LElSeWhnTV ZHbDG3yoqXLt4vrUHKAgaGku1QXEvoQM8naLh7MAMTZAq3GGjoCrMQcQRnOi+h+pGS vR3aOWoNb2O7YW8gqjz+/6zTF8CDF0ZyjJ6H1qSg105by/QQMASVVwFphgYCV91wF8 jnD0XhNaMuyig== Subject: Re: [dpdk-dev] [RFC] ethdev: introduce copy_field 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" > Tuesday, January 5, 2021 17:17, Thomas Monjalon > > RTE Flows API lacks the ability to save an arbitrary header field in > > order to use it later for advanced packet manipulations. Examples > > include the usage of VxLAN ID after the packet is decapsulated or > > storing this ID inside the packet payload itself or swapping an > > arbitrary inner and outer packet fields. > > > > The idea is to allow a copy of a specified number of bits form any > > packet header field into another header field: > > RTE_FLOW_ACTION_TYPE_COPY_FIELD with the structure defined below. > > > > struct rte_flow_action_copy_field { > > struct rte_flow_action_copy_data dest; > > struct rte_flow_action_copy_data src; > > uint16_t width; > > }; > > > > Arbitrary header field (as well as mark, metadata or tag values) can be > > used as both source and destination fields. This way we can save an > > arbitrary header field by copying its value to a tag/mark/metadata or > > copy it into another header field directly. tag/mark/metadata can also > > be used as a value to be stored in an arbitrary packet header field. > > > > struct rte_flow_action_copy_data { > > enum rte_flow_field_id field; > > uint16_t index; > > uint16_t offset; > > }; > > > > The rte_flow_field_id specifies the particular packet field (or > > tag/mark/metadata) to be used as a copy source or destination. > > The index gives access to inner packet headers or elements in the tags > > array. The offset allows to copy a packet field value into the payload. >=20 > So index is in reality the layer? How is it numbered exactly? It is a layer for packet fields, inner headers get higher number index. But is it also an index in the TAG array, so the name comes from it. > What is the field id if an offset is given? Field ID stays the same, you can specify a small offset to copy just a few = bits from the entire packet field or a big offset to move to completely differen= t area. > Can we say that a field id can always be replaced by an offset? Not really. You can use offset to jump around packet fields for sure, but i= t is going to be hard and cumbersome to calculate all the offsets for that. Field ID is much= more convenient. > > It is proposed to implement the "set copy_field" command to store all >=20 > You are talking about testpmd here? > It looks unrelated to this patch and not sure it helps understanding. I'm working on testpmd implementation and will send it shortly. > > the required parameters and then to use this template by specifying the > > index of the needed copy action. For example, to modify the GTP tunnel > > ID after the packet is encapsulated following testpmd rules are used: > > > > set copy_field width 32 src field tag index 1 offset 0 > > dst field teid index 0 offset 0 > > flow create 0 ingress pattern ... / end > > raw_decap index 1 / raw_encap index 2 / > > copy_field index 1 / end > > > > A more generic mechanism to overwrite an arbitrary header field may be > > introduced to the RTE flows implementation later: > > RTE_FLOW_ACTION_TYPE_SET_FIELD with the structure defined below. > > > > struct rte_flow_action_copy_field { > > struct rte_flow_action_copy_data dest; > > uint8_t *data; > > uint16_t width; > > }; > > > > This way we can have the generic way to specify an immediate value and > > use it as data for any packet header field instead of having separate > > RTE Flow action for each of the packet fields. Deprecation notice may > > be issued to RTE_FLOW_ACTION_TYPE_SET_XXX actions after the unified > > method of setting a value to any packet field is implemented. >=20 > Yes having a single action for setting any field looks to be a good idea. Thanks. >=20 > > Signed-off-by: Alexander Kozyrev > > --- > > lib/librte_ethdev/rte_flow.c | 1 + >=20 > We are very close to the -rc1 date and implemention is missing. > Please update. >=20 > > lib/librte_ethdev/rte_flow.h | 59 ++++++++++++++++++++++++++++++++++++ > > 2 files changed, 60 insertions(+) >=20 > [...] > > +enum rte_flow_field_id { > > + RTE_FLOW_FIELD_NONE =3D 0, > > + RTE_FLOW_FIELD_MAC_DST, > > + RTE_FLOW_FIELD_MAC_SRC, > > + RTE_FLOW_FIELD_VLAN_TYPE, > > + RTE_FLOW_FIELD_VLAN_ID, > > + RTE_FLOW_FIELD_MAC_TYPE, > > + RTE_FLOW_FIELD_IPV4_DSCP, > > + RTE_FLOW_FIELD_IPV4_TTL, > > + RTE_FLOW_FIELD_IPV4_SRC, > > + RTE_FLOW_FIELD_IPV4_DST, > > + RTE_FLOW_FIELD_IPV6_HOPLIMIT, > > + RTE_FLOW_FIELD_IPV6_SRC, > > + RTE_FLOW_FIELD_IPV6_DST, > > + RTE_FLOW_FIELD_TCP_PORT_SRC, > > + RTE_FLOW_FIELD_TCP_PORT_DST, > > + RTE_FLOW_FIELD_TCP_SEQ_NUM, > > + RTE_FLOW_FIELD_TCP_ACK_NUM, > > + RTE_FLOW_FIELD_TCP_FLAGS, > > + RTE_FLOW_FIELD_UDP_PORT_SRC, > > + RTE_FLOW_FIELD_UDP_PORT_DST, > > + RTE_FLOW_FIELD_VXLAN_VNI, > > + RTE_FLOW_FIELD_GENEVE_VNI, > > + RTE_FLOW_FIELD_GTP_TEID, > > + RTE_FLOW_FIELD_TAG, > > + RTE_FLOW_FIELD_MARK, > > + RTE_FLOW_FIELD_META, > > +}; >=20 > I don't really like having to list all fields of the world, > but it's probably better than the current situation of > creating a new action for each field. That is the idea, to get rid of the need to implement another action every time we want to modify another packet field. Let me know about a better way if any.