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 BC956A0524; Thu, 7 Jan 2021 21:15:15 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 34072140DB4; Thu, 7 Jan 2021 21:15:15 +0100 (CET) Received: from hqnvemgate24.nvidia.com (hqnvemgate24.nvidia.com [216.228.121.143]) by mails.dpdk.org (Postfix) with ESMTP id DBFD8140DB2 for ; Thu, 7 Jan 2021 21:15:13 +0100 (CET) Received: from hqmail.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate24.nvidia.com (using TLS: TLSv1.2, AES256-SHA) id ; Thu, 07 Jan 2021 12:15:13 -0800 Received: from HQMAIL101.nvidia.com (172.20.187.10) by HQMAIL107.nvidia.com (172.20.187.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 7 Jan 2021 20:14:58 +0000 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.172) by HQMAIL101.nvidia.com (172.20.187.10) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 7 Jan 2021 20:14:58 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QZZocBFhTEqOZ2swfCnDvRhrroN8L2qlGVaS+N4uD1RJYOKs6D4Bpl1HPvo48meTL3LMsD7R5+MTW2b46l6obpRCgQTXRYd2Ho0tc1C+OuAfJS3nuPRovW+1Wkl+VoCzSLejsaiWGaghdSbQ1GAx8Y0ceV019bKaZz8wxAJnYIHnHbEdzX5TuKSIPRmsN+rF14fL13zFgUYE/iVezAV+uL+ADvrY6/5kQox7KQUxM7OrXi79Cb8FbdakS1vniJvxyJHEqAN7kXPUhKvHrb9CuC82+wgBjt9yOFGHpRdKf/vtlCooBykW+UvGnuZ0Xe51b10G4OLMuZqtAnKHFER4QA== 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=kRvZrdCLJnCIkQh1GxWDGXMjB/0DNZ/bTDo1qaSvCvY=; b=ADsgcsv0jQoAWZRzc4O6uEXdYs4cJ3wsSTvPBcqDF56DUNc9TzmxMBzKYAhK8DMsIMpT2TbeV5DwqqhfV9X8wZkm9Nc73PSs3Ppt25vWaQLofVKqrrZQR8lnuG+71P8XhGpSa3M8jUPDxDYFdtzj1U+VSk41Z35AqrnxI62yKBe+VWvvxX76dRH1hhK7wgxW+BX5Cwe+weJC9eafgty+iB0yD8hlvFuIpnyddxfY8woXWy8s2P/zZXIHggIjy3FWd9Dck1RCJOB9+nAMvQAhlAM3icIu7e0aA5YE1CQj0OePeT8xldAq9F5LceSIf1x3WNjazxuM7lUukpZWl8gE/A== 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 BN6PR12MB1346.namprd12.prod.outlook.com (2603:10b6:404:1e::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3721.19; Thu, 7 Jan 2021 20:14:57 +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 20:14:56 +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" , "ajit.khaparde@broadcom.com" , "jerinj@marvell.com" Thread-Topic: [dpdk-dev] [RFC] ethdev: introduce copy_field rte flow action Thread-Index: AQHW1N2TdPEI29qYiUa+u6muk6TpcaoZtyQAgAKb6PCAABCegIAAAFHggAAC0gCAAABOMIAAGpGAgAAATqCAAAL9AIAAM30w Date: Thu, 7 Jan 2021 20:14:56 +0000 Message-ID: References: <20201218013129.25186-1-akozyrev@nvidia.com> <2354870.U5oG32Jqq5@thomas> <1964475.rDoTHco0nS@thomas> In-Reply-To: <1964475.rDoTHco0nS@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: 7c49b5dc-5668-4597-58bb-08d8b348e71d x-ms-traffictypediagnostic: BN6PR12MB1346: 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: x7Ld6CRAh9OuS/HxVGA6YL6mQXb0qQb2S56+54PI4escjkMNEzhFGe+XLWQDUZfN/NjUoNv8EAEmurGH/TWS33cDunDvy3t9vE2lDs4xFp0439k0BOt70FXGAsruRfndCcjJLIAAN1jpfmjKctxQ1EcD++8C0n+8qVp5PnJ+COycPLUmvOuyh+A3bkP1KidXHBQjW5GwKRbhiFj+5JTmVIyybsrai7TIZzp+R+qq0DsCgktLqoNUTYXYo0kHvvxDCExwjap4OxcLlYwo0Yn43MLH6Dmia9yXnRfnkLYXBxEOaYKoX0/XkXUhOTfvgEvMldCrG30RZ35sA2vrGGwSIUfXalJq8H7x0K59zQU8c2V0N1nZVwtDhC1RrlSNTFMgk1VPL4M6hH7jBUbrJucLNA== 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)(39860400002)(366004)(346002)(396003)(376002)(136003)(83380400001)(54906003)(7696005)(55016002)(2906002)(4326008)(71200400001)(52536014)(316002)(6916009)(33656002)(8676002)(66946007)(64756008)(9686003)(66446008)(66476007)(76116006)(6506007)(8936002)(86362001)(5660300002)(186003)(66556008)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?U9htQweWvEJWuu9MPm/Lb0VsOl1Y35bDNzFMQXZxbh2iIwubuO7V/eOrXQNg?= =?us-ascii?Q?F2WhnBu8AOoRcFf4WdCUPfJK0SMzPKkKQnloV38HwjHFap89RLUGL7Wfzxfn?= =?us-ascii?Q?SspOmJVdr7EjwbNJK1dXmXrl0ri5FJ8n7taM2FG88QB9EMUD/t4iZRJcEl5a?= =?us-ascii?Q?k+QKINx27pbdF2mjNAZViRwhtRrkUcOG/FQIy1EJKjdZquhdEy5P/zsg0ThL?= =?us-ascii?Q?IEGnVFGTOt7KcjfflvT2+FtTxaNRf50YBmIDabe8j47Pa3GL2cuSzS5gv5uS?= =?us-ascii?Q?O72szxt14zonm4jclKE7Z0W7hZ5TEeNCJ6DAQFpAI/YS9DIqenP5Hx7qI1y3?= =?us-ascii?Q?2KEwGxzJODss7xMnkDZV/2X7H+A9tmwQcwsuaOx4RDoGffQi2/L6p+JIIhMC?= =?us-ascii?Q?TFqpQscZZFHiBgt/TxK8BqUeB5d120st3Ng4lnfKXIQPPz39mWfjpfU08AtZ?= =?us-ascii?Q?AcK6mAn1XjiyOHtaIiC4BLnfjdok0wuzae+5RPCdC6T2rmV7OK4JhGROeVVG?= =?us-ascii?Q?3LMAoc+8SOjezF9TspCUWCCa4aQ+AKpr4yxeLD8XnJTlm3hDu+Ldt+xcJkyF?= =?us-ascii?Q?VL0TXkMSkMgU8bly8YDtrdOnRCId9tfbS9p5/wGLfcFoC/xqJyOp1P2Qs2c/?= =?us-ascii?Q?FLMF5xf2f9iRpygN2gKAjYQjluhc8zFjJh+1fJE+YWKsLrBSEkyXVj+JobNx?= =?us-ascii?Q?oHsweW2sY6ih8bKE4NZA+AKTdwgwO37hZSjrigXH84KKnTQ9mUJ426h5SQFD?= =?us-ascii?Q?TVkQz4PjARS9iK3RhJHueufkXs3dpb5pBcHBDqHFt0ap4noE+2jqN6paGIkT?= =?us-ascii?Q?HhRscrB5oQYfxpHZswtPFlgDVorFvI2p5OUsljAQ6nt6HC8B/WqibxKLqhun?= =?us-ascii?Q?93cHj7DhKwUrQ3Ew1iStiZwv3DtezxH32XOk695YCk7XiIwbQwKuGsbKQGEL?= =?us-ascii?Q?FfYq5RMXS5I+weT8iafioPTc8dNT/KYz9AK8jGh75S+M84Gzffo78SLYdysM?= =?us-ascii?Q?jiRy/lTYNkNVn1ku8a9/WgSWml2S4qGGqLcm+IKQ7Y8D62I=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: 7c49b5dc-5668-4597-58bb-08d8b348e71d X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2021 20:14:56.8273 (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: nDlNYXHLYbTBmMPRN72omSwRV/cTumjc0JhjEOCqEOlq+AMTG8relr5dHkGN3zcdxxQEBdUxCy3IgV8PWkPTig== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR12MB1346 X-OriginatorOrg: Nvidia.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1610050513; bh=kRvZrdCLJnCIkQh1GxWDGXMjB/0DNZ/bTDo1qaSvCvY=; 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=i8K8xHeZi9hnLqJ9Xfz/goS/Ga1RQZi6cJQ4ji3Vk3G/7Mcu6kESLp9lTleMtvpQd Yn+Y5RvzO1rQKE2G6mxdZwZoBz/s2EOFp+KmMgpAjixhXP9DFWApSHkhfPwWfF6UaO Ddm8AjJCwY8TGka2DlJwYBOMARaABFf/PqWC8fAR+PJR+D6Xhjs3/GYc0JgOkT9z8S Vg//AqOStVsY1wTTBV58b4V6NcJbU5VjktE+LoOB5dHkIkKssiY+x8NINmvQ1GgEDp qr0f8AKi48c0S/eFzkLiz4hkSTIU+NrTiPn2QDR3pFqLR31MXMu/GG1qrWjBKLhaBR zwNnup2sWel3g== 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" > 07/01/2021 17:57, Alexander Kozyrev: > > > 07/01/2021 16:22, Alexander Kozyrev: > > > > > 07/01/2021 16:10, Alexander Kozyrev: > > > > > > > > > Thursday, January 7, 2021 10:18, Thomas Monjalon > > > > > > > > > > > > > > > RTE Flows API lacks the ability to save an arbitrary he= ader field > in > > > > > > > > > > order to use it later for advanced packet manipulations= . > Examples > > > > > > > > > > include the usage of VxLAN ID after the packet is decap= sulated > or > > > > > > > > > > storing this ID inside the packet payload itself or swa= pping an > > > > > > > > > > arbitrary inner and outer packet fields. > > > > > > > > > > > > > > > > > > > > The idea is to allow a copy of a specified number of bi= ts 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 ta= g 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/me= tadata > 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 f= ield (or > > > > > > > > > > tag/mark/metadata) to be used as a copy source or desti= nation. > > > > > > > > > > The index gives access to inner packet headers or eleme= nts in > the > > > tags > > > > > > > > > > array. The offset allows to copy a packet field value i= nto the > > > payload. > > > > > > > > > > > > > > > > > > So index is in reality the layer? How is it numbered exac= tly? > > > > > > > > > > > > > > > > It is a layer for packet fields, inner headers get higher n= umber index. > > > > > > > > But is it also an index in the TAG array, so the name comes= from it. > > > > > > > > > > > > > > Sorry it is not obvious. > > > > > > > Please describe the exact numbering in tunnel and VLAN cases. > > > > > > > > > > > > > > > > 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 com= pletely > > > different > > > > > > > area. > > > > > > > > > > > > > > I don't understand what is an offset then. > > > > > > > Isn't it the byte or bit where the copy start? > > > > > > > Do you handle sizes smaller than a byte? > > > > > > > > > > > > It is the bit offset, you can copy 20 bits out of 32 bits of IP= v4 address > for > > > > > example. > > > > > > > > > > Now I'm confused. > > > > > You mean rte_flow_action_copy_data.offset is a bit offset? > > > > > > > > rte_flow_action_copy_data.offset and rte_flow_action_copy_field.wid= th > > > > are measured in bits, right. > > > > > > So the offset is limited to 16 bits? > > > How can it be useful? Is it an offset starting from the specified fie= ld? > > > > Why 16? It can be up to 2^16=3D65536 bits. Do you think that is not eno= ugh? >=20 > Yes 8KB may be too small for huge packets. > I recommend 32 bits. Sounds good, will make it 32-bit in the implementation. > > And it starts from the specific packet field pointed by the Field ID, c= orrect. >=20 > I think it would be more useful as a global offset > starting from the first bit of the packet. The API gives you this flexibility when you specify None as the Field ID. But Field ID is useful when you don't want to calculate the offset by yours= elf. You can just say: I would like to copy IP address in the inner header (inde= x 1), for example, and leave offset as 0 instead of trying to figure out where it= is: set copy_field width 32 src field ipv4 index 1 offset 0 dst field tag index= 0 offset 0 > > > > > > > > > Can we say that a field id can always be replaced by an o= ffset? > > > > > > > > > > > > > > > > Not really. You can use offset to jump around packet fields= for sure, > but > > > it > > > > > is > > > > > > > going to be > > > > > > > > hard and cumbersome to calculate all the offsets for that. = Field ID is > > > much > > > > > > > more convenient. > > > > > > > > > > > > > > I think it depends for who. > > > > > > > For some use cases, it may be easier to pass an offset. > > > > > > > For some drivers, it may be more efficient to directly manage= offsets. > > > > > > > > > > > > It is possible with this RFC, driver can choose what to use: id= and/or > offset. > > > > > > > > > > > > > > We can set field and index to 0, and use only offset? > > > > Yes, I'm not inending to put any restrictions against that. > > > > > Then it is a byte offset from the beginning mbuf.data? > > > > Yes, but it is still bit offset, not byte offset. >=20 >=20 >=20 >=20