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 B9CDFA0524; Fri, 8 Jan 2021 13:16:44 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7FA71140FA6; Fri, 8 Jan 2021 13:16:44 +0100 (CET) Received: from nat-hk.nvidia.com (nat-hk.nvidia.com [203.18.50.4]) by mails.dpdk.org (Postfix) with ESMTP id F2069140EBE for ; Fri, 8 Jan 2021 13:16:42 +0100 (CET) Received: from HKMAIL101.nvidia.com (Not Verified[10.18.92.100]) by nat-hk.nvidia.com (using TLS: TLSv1.2, AES256-SHA) id ; Fri, 08 Jan 2021 20:16:41 +0800 Received: from HKMAIL103.nvidia.com (10.18.16.12) by HKMAIL101.nvidia.com (10.18.16.10) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 8 Jan 2021 12:16:27 +0000 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (104.47.37.52) by HKMAIL103.nvidia.com (10.18.16.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 8 Jan 2021 12:16:26 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YJ03M8G5YuDsBo/2bmHcqW8j0HH8orUxST/Z2kNClpBwXpO/E/c9fAujLEIx5/MhDVzZqGTCfm3IslJ1lRT/C3XSZX6jBgPfrQ6wSApDSOE49rWR8xrCU0VYv1I+JmW5CXQp9m8F4wDr4nt/mQk6ePi3mcjKC3VQSLdtRDgyCdNNJK7KAVF7iB+S9+ZfKihh66yjFZ6+rdZDUnW8x07Rd6Y/V8lYq03iV7UgdtasgGWu+8aP81q5w0Dgex4DPOdMz+5ullntepsl6JY9xsYjhoitEOT/m+ouNQohuk1h8txAzj2rE+fuHddX3QwCtRexTQTL98IO9l8amOIVYELKQA== 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=z8o+U41rAnWf1U3EOZGa988CkULOsy7ZLl967+gyPow=; b=KSVm6yUywT5CzkVZRKgXRdmXJGGX6DloBVkrzMsnsVehLmHATInOLTJsJUXpiDfPHHZbokG0N14Tn3l1UtJO+x47jClK3nntIzXRz8Es4eV4ohXdMylrLLxz+5n9hhIuRQvI96TBN0ShYoLlRY/8BO4u2uDbm629NKdKUudSZmf/aFUiP21JzhXrwmB5nTVaiuvTFr0mAjMRZwzxCsRsLjaNPgxKuv8aPn+bfSAg6KpWwi8pViAN6VE2rsmiqb09kyjmoPZld3BBjMtBZW6CFk4ZRgqvsKI9M8juTGIcUWKXfNbVFthPHOvUYaucV0Xhgp1ljc/rF3Nzq/M7kkm3Qw== 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 DM6PR12MB3753.namprd12.prod.outlook.com (2603:10b6:5:1c7::18) by DM6PR12MB4529.namprd12.prod.outlook.com (2603:10b6:5:2ab::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6; Fri, 8 Jan 2021 12:16:14 +0000 Received: from DM6PR12MB3753.namprd12.prod.outlook.com ([fe80::e4a9:f9a1:d873:d07a]) by DM6PR12MB3753.namprd12.prod.outlook.com ([fe80::e4a9:f9a1:d873:d07a%6]) with mapi id 15.20.3742.009; Fri, 8 Jan 2021 12:16:14 +0000 From: Slava Ovsiienko To: NBU-Contact-Thomas Monjalon , Alexander Kozyrev CC: "dev@dpdk.org" , 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: AQHW1N2OXTAXEVW7T0isdZfvSAwL/qoZtyQAgAKewQCAAA3FgIAAAS+AgAAB9ACAAAErgIAAGbSAgAABAQCAAAJKAIABO7lA Date: Fri, 8 Jan 2021 12:16:14 +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: [95.164.10.10] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e81540e3-e0ea-49a6-b4fa-08d8b3cf31ce x-ms-traffictypediagnostic: DM6PR12MB4529: 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:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8MdiXRCxnDp5NS/2FkcdVl3SnnIxlofGXC0P4+e/AD1+I0K8BXbFR4wh5I9+9Yr8+92gugL2QMKPJxWhyUsIXp+0WIcz4jHQbduAG3XTRDeVq5VtpQPSQaoBh4Yf3rmB4x14jVrprEjGUCnABpRFkXwGrHIEa5TyAckuerWjZjgmPvC+iuEzadN/A20Q6Sn5eOr4VIMqQYeoDPcFyd9CE8RKzJ0sHdQN5YPfq1BTTiygZ4XssKJoysBH6/5O7ylndSsh7f3/1A7QE2ZA5ysy/c+ARSAbSIxeIh+vIIreLYB/owQR3HOok7XkPcpvVW9s75chtRZWaDJDhaBWj0GD7aYCb14EzrykjyQiy4+3MbtEyEZqMTY7Ar092SnKKlIm3XR21GH06pU532LfQZMX1g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR12MB3753.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(39860400002)(346002)(376002)(396003)(366004)(478600001)(52536014)(7696005)(8936002)(33656002)(6506007)(53546011)(26005)(186003)(5660300002)(4326008)(8676002)(71200400001)(6636002)(66946007)(9686003)(76116006)(66446008)(66476007)(66556008)(64756008)(55016002)(316002)(83380400001)(2906002)(86362001)(54906003)(110136005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?oT63BzZ7ehQAvqOyqcsy30neeBQbsYuOqVGgG0RECCDT8Pja3/O4kp+49boa?= =?us-ascii?Q?jU7AMvXarRWLAj+Lm9VKPDOlXrCwAcckp8HuZw0Mq9RYYzKYKPtLU72UfMqa?= =?us-ascii?Q?XS1ngBmK+2/hE6k3hzGTMrnwSTTEAeBkJlT7vNLnqRZArnMDwUStjWkkr+GU?= =?us-ascii?Q?J0HcJlATx0FYC2KugkPGiINlIsjkZQSIdB1KroMYd73UCHxcrlwsyhhEwj6n?= =?us-ascii?Q?hStthFQCzUjzBXEDmXHLj33YF1gnss2SFqJ/NcWVfkQw4vY75ilXSYm6rlKn?= =?us-ascii?Q?J//SC91a0V7b0/md28YV1ZHKW7J8CzqKwCLdMN0AfMQqQbUlRm8IpxNr9Uwh?= =?us-ascii?Q?TbWyC/na1GNUsY6BlUrlZHjHVwIa7iqhV9Fic/jGwDCc+9jrh/qJDu1RuhH2?= =?us-ascii?Q?mC4U2/B8V0MlsjzGTGXyHG4VQu1oWOTbH0ZAyewZZ2A2CiCsnSPYnbnPWgqq?= =?us-ascii?Q?u8mIRBs5yUggAiat/HuVWMR6BQpyVx8mQIW84mwnlqmJhI4PDodw5fvZMPup?= =?us-ascii?Q?y2/1pFV/0YGvZUueOcvavPBE98+Go/Jq9lyHotvsTN4UJtmF4DsfpnHhLwUW?= =?us-ascii?Q?R1ZGwl2GGBmfTvSp9mlmS1W4VH65osGxRm/B/cLJJaUMbtefqy7EHWeO8yCk?= =?us-ascii?Q?sinL/TgLRyr1oxXRd7l51o6XWpMBg/sieLHCFDIddxliQWiOvucig+rH164Y?= =?us-ascii?Q?RSpsALDQiKEv+2MUpQStKMpIrygDGtpxLJJQ72tBSgo+eJgu5ThxQiqXHJQS?= =?us-ascii?Q?ZkX7ZSCX7g4f2rxlpe9x2/fouz3llB1Et1kQD6yowAS1IfndWumkreJYQbGG?= =?us-ascii?Q?RStQ+bji1g9ZGZg5WqCaERvsACIEoB8byEmgPwNo0deLXMytLz0AwUXRpnMH?= =?us-ascii?Q?GR/mDSRaQ8pq7msYfxkvVXwXFRxv5LqnmTKB9a9dxvXBFNT11xNTIO/ybr7p?= =?us-ascii?Q?LfqsQKKWzQEFQ7fhwjCHpDRVf/T1FokR9tRiuD4yYOQ=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: DM6PR12MB3753.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e81540e3-e0ea-49a6-b4fa-08d8b3cf31ce X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2021 12:16:14.7368 (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: GNp43uNB655cZy2Oz+Wgs5t2x/O7wmoHZHe9ZING8mpPRbzOgaWRZ+wtf5QlxjXH+f39s0Ww2Vz2kC9maAKBpQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4529 X-OriginatorOrg: Nvidia.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1610108201; bh=z8o+U41rAnWf1U3EOZGa988CkULOsy7ZLl967+gyPow=; 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=Cs64ClFNvQmYsfcTZ4v36AUjD4Ig9AQZVLhUHWRTrCTXFiYoHOAdfuVVVl2VMGK11 U66gyrWpOdofzZ9qNdHAglAP16p9N6gvum/GFoo/zBlfVg4T8YJ3MZtAP7V9SlNrCY 4+K1lcduv2Ghgq6n7gvzO73DlbCejVZ1pQOvwu3ZuGyV9BGxFttt7RspNTmHOg4n6X 8b9ZYXvoHYAVim1XuW+hDFi1CDRRkaFwpyyNUaevRdWI9LsSpjm1Lu3a4lEtmmy+B1 zKjXyZkuRrXrOG6iFzzkJrkCc91cVB0Yf8ckRaNC3e7L6jWxgrDtVesNyCapBTKFFK iBu1/74crgATw== 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" > -----Original Message----- > From: Thomas Monjalon > Sent: Thursday, January 7, 2021 19:06 > To: Alexander Kozyrev > Cc: dev@dpdk.org; Slava Ovsiienko ; Ori Kam > ; ferruh.yigit@intel.com; > andrew.rybchenko@oktetlabs.ru; ajit.khaparde@broadcom.com; > jerinj@marvell.com > Subject: Re: [dpdk-dev] [RFC] ethdev: introduce copy_field rte flow actio= n >=20 > 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 > > > > > > > > > > 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 f= ield: > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > 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 > > > > > > > > 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 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.width 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. >=20 > > 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 firs= t bit of > the packet. M-m-m, sorry, I think this anchor (the first bit of the packet) is not appl= icable in general due to the field position in the packet is flexible and varying. For example, pack= et may contain=20 VLAN tag, IP header options, TCP options, or may not, and absolute offset=20 (from the packet beginning) does not work well.=20 Hence, to unambiguously specify the desired part (as bit field) of the pack= et we need the following indices: - protocol field, we do it with field enum, and field index (if any - in ca= se if we have multiple similar items in the packet - say, inner or outer IP, or array of metadata = tags) - the bit offset in the field - to specify the beginning of our target bitf= ield - the bitfield width in bits - to specify how many bits we would like to pr= oceed With this bitfield addressing approach we get the opportunity to manipulate= with bitfields in the almost any protocol fields. For example we could copy cong= estion control bits from inner IP header to outer one. We can have fine handling t= he bits=20 in metadata, and so on. > > > > > > > > > Can we say that a field id can always be replaced by an o= ffset? Theoretically we could consider defining some fixed packet structure and us= e offsets from there, say: MAC_DST is 0 MAC_SRC is 6 MAC_TYPE is 12 VLAN_TAG is 14 VLAN_TYPE is 16 .... But, there are to many variations in the possible packet formats - tagged/u= ntagged, CVLANs, IP4/6, IP options/extensions, the huge zoopark of tunnel... It woul= d introduce and ambiguity and would require to predefine a lot of packet formats.=20 With best regards, Slava