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 75642A0524; Thu, 7 Jan 2021 16:22:18 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3C18A140FD0; Thu, 7 Jan 2021 16:22:18 +0100 (CET) Received: from hqnvemgate25.nvidia.com (hqnvemgate25.nvidia.com [216.228.121.64]) by mails.dpdk.org (Postfix) with ESMTP id 2928D140FCA for ; Thu, 7 Jan 2021 16:22:17 +0100 (CET) Received: from hqmail.nvidia.com (Not Verified[216.228.121.13]) by hqnvemgate25.nvidia.com (using TLS: TLSv1.2, AES256-SHA) id ; Thu, 07 Jan 2021 07:22:16 -0800 Received: from HQMAIL109.nvidia.com (172.20.187.15) by HQMAIL109.nvidia.com (172.20.187.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 7 Jan 2021 15:22:05 +0000 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.175) by HQMAIL109.nvidia.com (172.20.187.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 7 Jan 2021 15:22:05 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eXu6BeWD9biE65AdlMSyZ4+ErKz5CbaREOupZp2sJ+0NpE3cC01mA42ixsVYpnJs/vnpRPflE9yWe5JLr1kS0t9MUtZs9hfmwuylMY7NQIOGE10WdfW8j2fKwwF/W6JAdHxHrTf2V3yoanGW+q3B3k6Zl3L15hbLQKGfVIR4BSDH4wPQ2q+WCTRHmXI6qRW/P2AkZTghSVhiWBbjgtr2lHPsVyafyRWyG/mCZLjvynLq32C9Y4K1aME1IZjU+chsbRCtT5kpeCHpStaCkzyofAGECoZB5ejpbRXVr2wtMTwsYyhAtUcXnLtM8e3X/f8lcWBlO2RVn5pHlPnPXS3Bog== 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=UgcEqq7DluzKgra2GEsZESxKrsP/0KXyk2iVX+9N4n4=; b=gTR41KtTgsy5MnR0Boib9V9ZSU5oZLkw2ZCyYiVY6s6oWvnSpoLBMcXy340V15TMDetLWV5a6tlMIDzzT9/mVqe/df4CLan13uiRe81PcYm1aSED4xSE/PJYzNqE1QRPDIePYW4aE3ECeP8yB8q1KTPhbsi0V/IKT7lE0x4IP3F1aTsszHT75OlB/OtuzdGHq4nTSOuJOk/zLhbJbyWliLkjGR7eiQz3oGlBVfXSUqACuVm0F/EpVpL+5uf5HVkkpcxXiSMWPjjfEEcbmPIFdxV3rlJEyu+Vk12X7okty/ND04lRnAPJ0c3Xh0snzGKIX0zpEaOqNoSl6W5CK/Mekw== 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 BN6PR12MB1506.namprd12.prod.outlook.com (2603:10b6:405:10::11) 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 15:22:04 +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 15:22:03 +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+u6muk6TpcaoZtyQAgAKb6PCAABCegIAAAFHggAAC0gCAAABOMA== Date: Thu, 7 Jan 2021 15:22:03 +0000 Message-ID: References: <20201218013129.25186-1-akozyrev@nvidia.com> <6314874.LEoM74Pqvz@thomas> <4077045.mHWWFMTU2l@thomas> In-Reply-To: <4077045.mHWWFMTU2l@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: 80f12295-2ab0-403d-fd7c-08d8b31ffcc4 x-ms-traffictypediagnostic: BN6PR12MB1506: 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: LUJuKBZZFO0wRgH9ScJ8YDsowBPZHtrDVyVg5r+Oultml9r9M8uN99w/zmeKInZPhlaLXkk1lDly6lg3jN4vmvCpAgIa/SsHWsCBmwJ8Pu3uNmMgzOc/s9DfZxTTikVBgXqZE5dRPVQ2T1h1aD2VG9ilELCLi+F30L0QZPfhdjdY2k0w0xKo77VAVopQq9k4shn3EJGikfKn8XqN28ltE2wr34261RW/rzwLOIFl6zBQoW6V2j3KTapRbA/cZcf0HgEpM3QCjpYQ4JYB/diaJ+dcTl6n+A6WFeOULb4Gex2rA2mKGmhOlMv9AcxZPZvjdv/rbXZL4qqfag/JnAdCIMnLGPaM/eqEE1Ojt5UvwfMNliQGykIlvT5UAGz+z/lBtlMxpdIgHZ4YZ0qIAloaWg== 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)(376002)(39860400002)(366004)(396003)(346002)(136003)(76116006)(55016002)(52536014)(9686003)(8676002)(7696005)(5660300002)(71200400001)(66446008)(66556008)(66946007)(2906002)(6506007)(64756008)(54906003)(316002)(83380400001)(478600001)(86362001)(33656002)(4326008)(186003)(66476007)(8936002)(6916009); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?GeSUwMi9aAxsIZCokONU8ckTY9S9RRwaS4GIuzfEeRxlpeg7onVAYjitwDOw?= =?us-ascii?Q?hAYzX+0nkOatyDDRGG6T8uKJXFYTzwFaKKNteCaj1Xf2t4XEKVlkAy8CVD/g?= =?us-ascii?Q?SHCU+FOHrh7QZTxtu0tR8MiqqRCy0PW20uGPvglMADaq9D5ABK6mNeH2VmCO?= =?us-ascii?Q?DKn2s3moQqGk+OGgx7v37rjAF0/a2adZJePu6l1/icocdAJ6RgtfbRYMBfQl?= =?us-ascii?Q?xX7yyi9z6ZSIjefXYWgfGh69Z8kfYxR5NpLqr7xjFA6hu0/iOej35mADeuLm?= =?us-ascii?Q?cBqYBRWPVr1CDRJ4RDyCeJJXZkCI9UBMtyTfPy3pCLOoNSK5aRfGX7i6KMG9?= =?us-ascii?Q?ETh4G8ZQj1u+hwGyfAgAnuSlz1v9i4CK4s5plWTVQ9zTwVRUMGIc+Vm6Mc1N?= =?us-ascii?Q?kuMFsOJQltk+7olGq4+14YdKbkGuDpO/4exzOi/NNvi2DmHxCpUTM0Wo8xGW?= =?us-ascii?Q?CLO02jKLbxZ8eZbr0v0pRS6N0Rs8S8jy/B7H+Az+ytvoF9s4scUhVN4DWuSC?= =?us-ascii?Q?rDBgN7PvfQHNqqjw939v5F9BUtRQZnW9bx0fMSPFDtf+cQtBwGm7EcJyB3Wn?= =?us-ascii?Q?c392XyPQYXNRmIDEy75tv8g27sDp/tukhjfJ4MAGsv1ITZzrTtPGTIl2Rcdg?= =?us-ascii?Q?VpRL3DWy6GkrX/1lto9Mqvx4o/93IxM25oI8PtxIMK9EgUhvVYvMtGEaxxD5?= =?us-ascii?Q?b2pOWAtk8SzGEy+XaYEhU+C7/gpc+Dwk03g55BCmvu6s3RKn8r4kwWQfVPPH?= =?us-ascii?Q?vKcq6KCjIB1D+ezuMjn8wTMz8w01IWodNhowJ1cFuyZ7uP/Z/k9a6BwiUc7a?= =?us-ascii?Q?NLUsKcVRDCJ2SDLardQX5Dtt5qv/s/8ucMGx+espTC+eg/gxuZBsOkMxeEAy?= =?us-ascii?Q?ziFBRenMfjxCRLn1bekNCs51u8v5QsPKFf+O0uJ0lQP6F47wx9cb0YfJC+ls?= =?us-ascii?Q?1E6DVswElOS+EMewtihbG5SH9KVss1fQ62UqC1BpJsB6+FVG3FCDu7sIiBEf?= =?us-ascii?Q?n/u5kCF+erdjhzO844guFx3mYVrtNAX62ebu8T+LKfZUiLk=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: 80f12295-2ab0-403d-fd7c-08d8b31ffcc4 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2021 15:22:03.7372 (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: ssuVg8sOeaRx9IRygrMiFZgSG9sO3qLWpa7v+S7TTYNToQXq5lWTtNoLHOU51ZsTHPKuBbaau92lo3g2NQFYcA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR12MB1506 X-OriginatorOrg: Nvidia.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1610032936; bh=UgcEqq7DluzKgra2GEsZESxKrsP/0KXyk2iVX+9N4n4=; 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=q/ThOfVb5g3AAC/bVVS3gtK/+ZwNotH1kjAMNFIfdb+BXhkc4o12jvl+BmmkBTYfp 24k25RMJrWmbcvoekzaTKnaoSgSEloJqWFRv+B8opJvj+aewiQZvtcjzbzz6EAAvqw 6rT0aQD/e5YGrD7QBJ2M1Wia9VJqGiBFQSUBTn2P00v+ibPmmHczVY5kiYuzX2wILs pGVNqG7Q4l1voEW7c5rc2Q5mLkV8bQBqTfrYcZatcJLBpYo8xZHorBJgXuVyNq1I4V p/z3j9m69p7sdiAvjRarhKZu6QhNHTuI5PbneSCim1SYOzoDu44LHDDLb7YZo/kZOS ZKq/3PlMEvB0w== 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 16:10, Alexander Kozyrev: > > > > > Thursday, January 7, 2021 10:18, Thomas Monjalon > > > > > > > RTE Flows API lacks the ability to save an arbitrary header fie= ld in > > > > > > order to use it later for advanced packet manipulations. Exampl= es > > > > > > 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 sav= e an > > > > > > arbitrary header field by copying its value to a tag/mark/metad= ata or > > > > > > copy it into another header field directly. tag/mark/metadata c= an also > > > > > > be used as a value to be stored in an arbitrary packet header f= ield. > > > > > > > > > > > > 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 t= he tags > > > > > > array. The offset allows to copy a packet field value into the = payload. > > > > > > > > > > So index is in reality the layer? How is it numbered exactly? > > > > > > > > It is a layer for packet fields, inner headers get higher number in= dex. > > > > 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 jus= t a few > bits > > > > from the entire packet field or a big offset to move to completely = 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 IPv4 addre= ss for > example. >=20 > 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.width are measured in bits, right. > > > > > 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 sur= e, 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. >=20 > 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.