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 3CCE9A04B5; Sun, 10 Jan 2021 07:50:40 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B7B10140E42; Sun, 10 Jan 2021 07:50:39 +0100 (CET) Received: from nat-hk.nvidia.com (nat-hk.nvidia.com [203.18.50.4]) by mails.dpdk.org (Postfix) with ESMTP id 00107140DAA for ; Sun, 10 Jan 2021 07:50:36 +0100 (CET) Received: from HKMAIL104.nvidia.com (Not Verified[10.18.92.77]) by nat-hk.nvidia.com (using TLS: TLSv1.2, AES256-SHA) id ; Sun, 10 Jan 2021 14:50:35 +0800 Received: from HKMAIL103.nvidia.com (10.18.16.12) by HKMAIL104.nvidia.com (10.18.16.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 10 Jan 2021 06:50:20 +0000 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (104.47.44.52) by HKMAIL103.nvidia.com (10.18.16.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sun, 10 Jan 2021 06:50:20 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kgzQvG0MNC4YROo5sz1ASCi+ltjft6mXE30K3ryTx4j36WKVhaQbGWyXJWyVwTyUN8s/VIpIGYEGPAJH/dS2hHSixJxNto+3z40IosW9rjaWmAFhmOV/IOVvBFE6nHi2EHEHZT1FtYzKaHjdEPBLTIuS0RoHtDgfdib9CRemZA7YtkEUOORcmqiKmV1MW9ekry0C+cZx1cymr+BLM2Ja9h4sUm2irgqjPu4HEvIE92n6MGZalFRLMgNiIebkVtzmDJeMcqPrRxnB49lXRNqtPohj8ezEoc2zHHqjTy5BvAdRLf1fMDrx9FO6OhYsJ+WrMYi/ZLzsEZ4QcrnPf5TQ9g== 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=0UKLQknLxIihnRcafDKeA3gObCqaB2CnnXwIb3CUZXw=; b=fX/adFEc76uexTgGuBTotmExT4QlsBikD8OFCAhg7/ky3pyP58qx7koNZ60gClPCdpKXf8HQfwkKAk4Q7+/gg3o0mqZTMXb5/2B8HdwnxVPRb5GwdqE5u64rkzAGVKZ3h2OiWBqD2vBBj8uuCqX4mL8cKNjlu/SLNZm7gmM3MkqrEq3I2PXHGo4Q1FV8rc93oWAJp6DuPBagIdul8xw/iH4QYmFXQqlb1VcVYplDunurUnv7rE+8t0oWVV8a7Hun65ym5PD+X/9dXED5w1s4lu8JcKsf1ydG2H488N69UjTGvamK9ejEfmdiCMw3ogHYjlodANoBnHKbWGdvjesqBQ== 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 (20.179.48.223) by DM6PR12MB3867.namprd12.prod.outlook.com (10.255.175.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6; Sun, 10 Jan 2021 06:50:17 +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; Sun, 10 Jan 2021 06:50:17 +0000 From: Ori Kam To: Slava Ovsiienko , NBU-Contact-Thomas Monjalon , Alexander Kozyrev CC: "dev@dpdk.org" , "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: AQHW1N2MsnhYRSM4mk2icUpkKP/6YqoZtyQAgAKewQCAAA3FgIAAAS+AgAAB9ACAAAErgIAAGbSAgAABAQCAAAJKAIABQWsAgALJLRA= Date: Sun, 10 Jan 2021 06:50:17 +0000 Message-ID: References: <20201218013129.25186-1-akozyrev@nvidia.com> <2354870.U5oG32Jqq5@thomas> <1964475.rDoTHco0nS@thomas> In-Reply-To: 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: a6a05ff4-e38e-4891-4835-08d8b533fd95 x-ms-traffictypediagnostic: DM6PR12MB3867: 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: OaL3qcnppaBGjdXjMf5euk16BlhxuucXkKhufFtGQJD7IXF5geqXj+maD+SyGRotZwKsU3rGktgeejYJhdqnqUnttY2XrRXa6w3qKYesyFPhuDSPk9VrfM6bJa0yCeutX9lohA/gX3lWu00l2Oiet2aGTNXMK/eWhIirzG367oQPvXDk37wYi5IyT169AA6xVJ5mTUR7i+sayAzYip3Tg0OaPuRLGMGHEZWGzeIihqIbDEuATLJCRcKbDhVGbIh9A3GYRPRqVM2hs42uHnRbVhMwy8BJjiUl9zLhr4lawmpWPlJRCEH9JgpNY9oCcpR9jQ7ug84x4xnjnEV7ZhhJQr2hQB6y8o5rZeziMqYwuKnjbinh7n8wsWl86do35xwhqD72Y0Ene/b60TYVV5tSLQ== 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)(366004)(346002)(376002)(396003)(39850400004)(136003)(316002)(5660300002)(86362001)(33656002)(55016002)(186003)(9686003)(66946007)(8936002)(2906002)(110136005)(54906003)(7696005)(76116006)(6636002)(26005)(71200400001)(8676002)(52536014)(66476007)(64756008)(4326008)(66446008)(66556008)(478600001)(53546011)(6506007)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?cE28XY+lLnaHNzkgJlUPc78dfc2wabYKaFu0xP9nzG0DwdrX3VJu9iTf/e8V?= =?us-ascii?Q?PaP2JNxsdIfBSIz3Ov4Yb/c72FnIUsNY43tb18nkRYdsEd4BmGXlj9+f0rm8?= =?us-ascii?Q?Fyw9wzccecMSfnYXP85ELp3RhUIEyniqFcTin1WRkQI/0PcQO+864vVuMsTX?= =?us-ascii?Q?9IGU0F3zHwrRRiseQV52kcOSKO81PZa7jDkRiHZEWQM4yd3EUt4rtDki52Yz?= =?us-ascii?Q?dcfeO2J19cI7BYvmFZo9dh/Qn/M/18R07kEoHcPTxbz4w1UZlhi0prY6zjKj?= =?us-ascii?Q?SfNQdVIGsDLogAoKZWXI8ICUpu8oBpvOpIJG44/5963WeU+ZZbXBiWLBvyi9?= =?us-ascii?Q?k8yNpE4/cNOgTJl2rDv46M8gbghAmDKS4tEMP3Vkgh8XsL6MjXRtvUnujyzb?= =?us-ascii?Q?kT8leWYqgVEZxR3/bDMNKpKxpxSD+hSbOmQ/nl2D031M5bY1XtapbaI1CRSZ?= =?us-ascii?Q?RISGCUsjlj6I2bMzlEJyLklDSeERPbHQt6XpLrjaLEv2CYLGHfcnaAHjaecU?= =?us-ascii?Q?x2HvWSHI4dS2VwN7NjgoPi6McVgFusLWR5sCfOR+Yf9gXmCJ/grrWfVszHKM?= =?us-ascii?Q?icZdZm/+OpSjvQjNK1Ei1mPuNtkgyKjI/f2FOoHLSZJte/7CheNK68yMVWM9?= =?us-ascii?Q?6ukF2tvuMhvhiSH1CCOIdsUPGfQsfGEiYkcABlYhlo9LuPHqlT3myRLG9Eyr?= =?us-ascii?Q?/F+aQs3Pw70tLndtTcg2VsWpFs1lm7xOHZFMjR6E778IuaV8vhj/TexXltPh?= =?us-ascii?Q?Nm8y8T1dhcqHwT0ToXg7sjOglIEHenFSz5/efmf+r/miE7VKzAAyzlB/i10P?= =?us-ascii?Q?q0pV0+MEdMoq1PY79bTdCnW7PpKzIzpv6oxG00jJO/bpfZJ4sHME3vMIM3zB?= =?us-ascii?Q?S4CemIX5f/ejRZkecCCUJONHKz+E5+zpCV5sXKEpP5TPaoDh7csQ/67SfWkQ?= =?us-ascii?Q?aY54PW2XHRtF/Uq/eHWFPA5r0STSEWhtqdXNEofUWVA=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: DM6PR12MB4987.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a6a05ff4-e38e-4891-4835-08d8b533fd95 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2021 06:50:17.4164 (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: sH7l0SWi3TyWmNYkicJwkmvo6Q4MSMyItdxMhLXop/zRcYTGI6UANga2U+Kym07PNEzkr9ANdAx/flvdU7aAcw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB3867 X-OriginatorOrg: Nvidia.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nvidia.com; s=n1; t=1610261435; bh=0UKLQknLxIihnRcafDKeA3gObCqaB2CnnXwIb3CUZXw=; 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=KR3G9cabDaOz0dTrL8pKn6SUq+bsrw8+KI175roNxgaVuua88PG12J6P6leAQQ4lX xbadaq1YjJuNl4tGlBKRimhlZFFjffWOUexB+eL1nWNGCMRu0yl5R8+5x37wlyFlr/ V2YZLlG7dflHu7musSwuVgwNtzdg8bqOhSPogDQEvXRXJyQecFY0JAiVC6Bc61buUM 8PXc3vsd3l8v3q19r1l4LRoC/cAHLdPbxxQtmcVozD04PmNT9p0Tyf0QP5Cj9glcbp H63Mib7h5n0mfyq2cgIARt+yU0fTbaGQaTJ5MXFQUBKYsj4SCbGQgz6lYtik9NhQI3 H9iekE/fmrzFA== 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" Hi > -----Original Message----- > From: Slava Ovsiienko > Sent: Friday, January 8, 2021 2:16 PM > 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 > Subject: RE: [dpdk-dev] [RFC] ethdev: introduce copy_field rte flow actio= n >=20 > > -----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 act= ion > > > > 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= 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 packe= t 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 ex= actly? > > > > > > > > > > > > > > > > > > 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 com= es from > it. > > > > > > > > > > > > > > > > Sorry it is not obvious. > > > > > > > > Please describe the exact numbering in tunnel and VLAN case= s. > > > > > > > > > > > > > > > > > > What is the field id if an offset is given? > > > > > > > > > > > > > > > > > > Field ID stays the same, you can specify a small offset t= o > > > > > > > > > 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 f= ield? > > > > > > Why 16? It can be up to 2^16=3D65536 bits. Do you think that is not e= nough? > > > > Yes 8KB may be too small for huge packets. > > I recommend 32 bits. > > > > > And it starts from the specific packet field pointed by the Field ID,= correct. > > > > I think it would be more useful as a global offset starting from the fi= rst bit of > > the packet. >=20 > M-m-m, sorry, I think this anchor (the first bit of the packet) is not ap= plicable in > general due to > the field position in the packet is flexible and varying. For example, pa= cket may > contain > VLAN tag, IP header options, TCP options, or may not, and absolute offset > (from the packet beginning) does not work well. >=20 > Hence, to unambiguously specify the desired part (as bit field) of the pa= cket we > need the following indices: > - protocol field, we do it with field enum, and field index (if any - in = case if we > have multiple > similar items in the packet - say, inner or outer IP, or array of metadat= a tags) > - the bit offset in the field - to specify the beginning of our target bi= tfield > - the bitfield width in bits - to specify how many bits we would like to = proceed >=20 > With this bitfield addressing approach we get the opportunity to manipula= te > with > bitfields in the almost any protocol fields. For example we could copy > congestion > control bits from inner IP header to outer one. We can have fine handling= the > bits > in metadata, and so on. >=20 +1=20 > > > > > > > > > > Can we say that a field id can always be replaced by an= offset? > Theoretically we could consider defining some fixed packet structure and = use > offsets from there, say: > MAC_DST is 0 > MAC_SRC is 6 > MAC_TYPE is 12 > VLAN_TAG is 14 > VLAN_TYPE is 16 > .... >=20 > But, there are to many variations in the possible packet formats - > tagged/untagged, > CVLANs, IP4/6, IP options/extensions, the huge zoopark of tunnel... It wo= uld > introduce > and ambiguity and would require to predefine a lot of packet formats. >=20 > With best regards, > Slava Regards, Ori