From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 75E97A00E6 for ; Wed, 10 Jul 2019 18:37:50 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 03ED42F42; Wed, 10 Jul 2019 18:37:49 +0200 (CEST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00061.outbound.protection.outlook.com [40.107.0.61]) by dpdk.org (Postfix) with ESMTP id B068C160 for ; Wed, 10 Jul 2019 18:37:47 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Zq8FjRq76QAS2zaBqXriheCWBo35E2ysOuL/hCxoHYLLEIcptfp8oydzD1EIp1gRypRrM0CwAVDwE/rynjtBhO+B1TgNXZrt0xNILh1Q0/SFAtWdG+xGSRIMDvOTOB4bvZbzJ3jV5HD9vXdGViaWM8OWy6AJxb2CGr6w6edQKWbm4Nvf2si1bcjo3LsOdn85mC28ZiauwgRKvcS1RfoE/RgHwdEDOLavYWSkbm8wjT4YlMyoOln6pnUb+g1RpPvCSoLYFBPd8ohlVNRSKscY1+reWX28JFv3ibjpUhnmbAxcRdzo4obQ6XwzOOZmh5UkX/40P7CioNZgJQzv7jtbTQ== 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=WHXr+bUxMkXuiW6X3NMlttLrjIfRltGYmM40he8wFHo=; b=mpHIknSpIpm9UsNbQESQagG3t+KaxE/14COt9VMTS+wa4WnxVtbm5UW+HEPsCeg00V4vP03wgUG3OsGCsr7J90HpK6ysryGZYxz/An4EpVHuoM87ceBu27f2CgoPsuv6gL4qIFpQt194rcguI30jYZPZ9zHWkYSZildN+wha81Ebf9DqNMm9sHnefHcxfhnS4D6sTX0FVhuz1i81h3wk5CCzLwNEKoyPFMc1A2yCqBdOWcGml4SHNeZzdl6a4JIOD/t5cTWzdMuEFLh8d5GnYQ+43/QMhc+sURXMMzyy6hYHm2jXc+ogCe/qPmZmaVfP7doTecoM/hAzEmCGO8rOwg== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=mellanox.com;dmarc=pass action=none header.from=mellanox.com;dkim=pass header.d=mellanox.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WHXr+bUxMkXuiW6X3NMlttLrjIfRltGYmM40he8wFHo=; b=lgEeV/L+3CrYEFaQK0iMPGtrKfhvX2JFRtaqvTed9nu+Eh9QCbgViA1Y0LAEnRX/MheKC7ckLn71CjXJUomT7BbMvAAklIHUUJPgcUAr35QlCZYBLh9KeUCQGLb4C5OecCS7Mv555g/DoELACGnLkVP5nDVCcQZsG/Hd1YcWziY= Received: from DB3PR0502MB3980.eurprd05.prod.outlook.com (52.134.72.27) by DB3PR0502MB4010.eurprd05.prod.outlook.com (52.134.66.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Wed, 10 Jul 2019 16:37:46 +0000 Received: from DB3PR0502MB3980.eurprd05.prod.outlook.com ([fe80::69c1:c0d7:1fa1:f89f]) by DB3PR0502MB3980.eurprd05.prod.outlook.com ([fe80::69c1:c0d7:1fa1:f89f%6]) with mapi id 15.20.2073.008; Wed, 10 Jul 2019 16:37:46 +0000 From: Yongseok Koh To: Thomas Monjalon , Olivier Matz CC: Bruce Richardson , Andrew Rybchenko , Adrien Mazarguil , Shahaf Shuler , Ferruh Yigit , dev , Slava Ovsiienko Thread-Topic: [dpdk-dev] [PATCH] ethdev: extend flow metadata Thread-Index: AQHVNwJTzsVA6SNmokWymtMInhcc1abDnTcAgAADZYCAAB/JgIAABwcAgABGKYA= Date: Wed, 10 Jul 2019 16:37:46 +0000 Message-ID: <5D78C242-D970-4001-B8CE-268D4E444BC6@mellanox.com> References: <20190603213231.27020-1-yskoh@mellanox.com> <20190710100743.z5ioyxish4wnh3s4@glumotte.dev.6wind.com> <20190710120128.GC505@bricha3-MOBL.ger.corp.intel.com> <6507101.CIctlFmaPS@xps> In-Reply-To: <6507101.CIctlFmaPS@xps> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=yskoh@mellanox.com; x-originating-ip: [209.116.155.178] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d3bb75a3-4215-4a54-b76a-08d70554f067 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:DB3PR0502MB4010; x-ms-traffictypediagnostic: DB3PR0502MB4010: x-ld-processed: a652971c-7d2e-4d9b-a6a4-d149256f461b,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0094E3478A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(136003)(366004)(396003)(39860400002)(52314003)(199004)(189003)(66066001)(66946007)(6486002)(66556008)(91956017)(66476007)(76116006)(33656002)(66446008)(64756008)(71190400001)(71200400001)(14454004)(6436002)(229853002)(2906002)(99286004)(25786009)(6116002)(3846002)(53936002)(81156014)(81166006)(8676002)(107886003)(6246003)(305945005)(7736002)(5660300002)(6512007)(14444005)(76176011)(256004)(26005)(86362001)(2616005)(186003)(6506007)(53546011)(478600001)(102836004)(476003)(486006)(316002)(446003)(68736007)(8936002)(54906003)(36756003)(110136005)(11346002)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR0502MB4010; H:DB3PR0502MB3980.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: BzoBPteLC7pZ0II4ZJjv31OY5W7PN1Pqym560I+RQn0CsdnGB7dqWghsLjCGYL4+tq+5aYR62JPVCdi4Ks8Ol4i6KnGPRFLOpk60W9qRmxiIVzwqvw0svzjWIi+rTOwuT6tycLY6qdkYJTl8bsd7haiVj9ruz0Fs/0zX9g4V8KYYqd7Uf72QDQU47QQUbO5uztJdWGn9niayUCxGaj8Hc+y7prd1uOS+I8nhXhqbpgYrwV8Q+Dman059ASL9W8XKiS8FygpgdDbcto7s1lFUGGDELwtch1AsCwupTvD0N+2PZ6aX8sDu5jS9xg0pUVaUdd5eAtpAmhIIF6O86dbyqXtNVYRlKpaJGYiRrf9136jVnxLotaiZHfsN6cjwpRXXOOixVOKd9zTiQNLmWa2GsANf12BV3wyrNe4lLM5XV2Y= Content-Type: text/plain; charset="us-ascii" Content-ID: <2614659F775A484CB60B88B22A0532AE@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: d3bb75a3-4215-4a54-b76a-08d70554f067 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2019 16:37:46.4355 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yskoh@mellanox.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR0502MB4010 Subject: Re: [dpdk-dev] [PATCH] ethdev: extend flow metadata X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" > On Jul 10, 2019, at 5:26 AM, Thomas Monjalon wrote: >=20 > 10/07/2019 14:01, Bruce Richardson: >> On Wed, Jul 10, 2019 at 12:07:43PM +0200, Olivier Matz wrote: >>> On Wed, Jul 10, 2019 at 10:55:34AM +0100, Bruce Richardson wrote: >>>> On Wed, Jul 10, 2019 at 11:31:56AM +0200, Olivier Matz wrote: >>>>> On Thu, Jul 04, 2019 at 04:21:22PM -0700, Yongseok Koh wrote: >>>>>> Currently, metadata can be set on egress path via mbuf tx_meatadata = field >>>>>> with PKT_TX_METADATA flag and RTE_FLOW_ITEM_TYPE_RX_META matches met= adata. >>>>>>=20 >>>>>> This patch extends the usability. >>>>>>=20 >>>>>> 1) RTE_FLOW_ACTION_TYPE_SET_META >>>>>>=20 >>>>>> When supporting multiple tables, Tx metadata can also be set by a ru= le and >>>>>> matched by another rule. This new action allows metadata to be set a= s a >>>>>> result of flow match. >>>>>>=20 >>>>>> 2) Metadata on ingress >>>>>>=20 >>>>>> There's also need to support metadata on packet Rx. Metadata can be = set by >>>>>> SET_META action and matched by META item like Tx. The final value se= t by >>>>>> the action will be delivered to application via mbuf metadata field = with >>>>>> PKT_RX_METADATA ol_flag. >>>>>>=20 >>>>>> For this purpose, mbuf->tx_metadata is moved as a separate new field= and >>>>>> renamed to 'metadata' to support both Rx and Tx metadata. >>>>>>=20 >>>>>> For loopback/hairpin packet, metadata set on Rx/Tx may or may not be >>>>>> propagated to the other path depending on HW capability. >>>>>>=20 >>>>>> Signed-off-by: Yongseok Koh >>>>>=20 >>>>>> --- a/lib/librte_mbuf/rte_mbuf.h >>>>>> +++ b/lib/librte_mbuf/rte_mbuf.h >>>>>> @@ -648,17 +653,6 @@ struct rte_mbuf { >>>>>> /**< User defined tags. See rte_distributor_process() */ >>>>>> uint32_t usr; >>>>>> } hash; /**< hash information */ >>>>>> - struct { >>>>>> - /** >>>>>> - * Application specific metadata value >>>>>> - * for egress flow rule match. >>>>>> - * Valid if PKT_TX_METADATA is set. >>>>>> - * Located here to allow conjunct use >>>>>> - * with hash.sched.hi. >>>>>> - */ >>>>>> - uint32_t tx_metadata; >>>>>> - uint32_t reserved; >>>>>> - }; >>>>>> }; >>>>>>=20 >>>>>> /** Outer VLAN TCI (CPU order), valid if PKT_RX_QINQ is set. */ >>>>>> @@ -727,6 +721,11 @@ struct rte_mbuf { >>>>>> */ >>>>>> struct rte_mbuf_ext_shared_info *shinfo; >>>>>>=20 >>>>>> + /** Application specific metadata value for flow rule match. >>>>>> + * Valid if PKT_RX_METADATA or PKT_TX_METADATA is set. >>>>>> + */ >>>>>> + uint32_t metadata; >>>>>> + >>>>>> } __rte_cache_aligned; >>>>>=20 >>>>> This will break the ABI, so we cannot put it in 19.08, and we need a >>>>> deprecation notice. >>>>>=20 >>>> Does it actually break the ABI? Adding a new field to the mbuf should = only >>>> break the ABI if it either causes new fields to move or changes the >>>> structure size. Since this is at the end, it's not going to move any o= lder >>>> fields, and since everything is cache-aligned I don't think the struct= ure >>>> size changes either. >>>=20 >>> I think it does break the ABI: in previous version, when the PKT_TX_MET= ADATA >>> flag is set, the associated value is put in m->tx_metadata (offset 44 o= n >>> x86-64), and in the next version, it will be in m->metadata (offset 112= ). So, >>> these 2 versions are not binary compatible. >>>=20 >>> Anyway, at least it breaks the API. >>=20 >> Ok, I misunderstood. I thought it was the structure change itself you we= re >> saying broke the ABI. Yes, putting the data in a different place is inde= ed >> an ABI break. >=20 > We could add the new field and keep the old one unused, > so it does not break the ABI. Still breaks ABI if PKT_TX_METADATA is set. :-) In order not to break it, I= can keep the current union'd field (tx_metadata) as is with PKT_TX_METADATA, ad= d the new one at the end and make it used with the new PKT_RX_METADATA. > However I suppose everybody will prefer a version using dynamic fields. > Is someone against using dynamic field for such usage? However, given that the amazing dynamic fields is coming soon (thanks for y= our effort, Olivier and Thomas!), I'd be honored to be the first user of it. Olivier, I'll take a look at your RFC. Thanks, Yongseok