From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10048.outbound.protection.outlook.com [40.107.1.48]) by dpdk.org (Postfix) with ESMTP id 5E356288C for ; Fri, 18 Jan 2019 06:27:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=47321v8WKVJhyfx8vSCWxxSxlf6GlVTazGQkTVjGIYA=; b=VORoQVbG4EE+uiaB8W/Qpxr4Uzv2vUcN4DgguCJBqSR+DOfBOLzEYHGApsmpCSXyKtom27ZzarXbR4vq+fRRyVckQtXE/tKXioukNcZPG9Z2DVt6Oku9FwKuxtW0aHe94hGTxkGPNQkHdUndoKlZGUMfxMmtdpvnMdV+ik+KR9U= Received: from AM6PR08MB3672.eurprd08.prod.outlook.com (20.177.115.76) by AM6PR08MB4263.eurprd08.prod.outlook.com (20.179.5.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1537.24; Fri, 18 Jan 2019 05:27:31 +0000 Received: from AM6PR08MB3672.eurprd08.prod.outlook.com ([fe80::25ec:2db7:d268:2b7b]) by AM6PR08MB3672.eurprd08.prod.outlook.com ([fe80::25ec:2db7:d268:2b7b%2]) with mapi id 15.20.1537.018; Fri, 18 Jan 2019 05:27:31 +0000 From: Honnappa Nagarahalli To: "Eads, Gage" , "dev@dpdk.org" CC: "olivier.matz@6wind.com" , "arybchenko@solarflare.com" , "Richardson, Bruce" , "Ananyev, Konstantin" , nd , nd Thread-Topic: [dpdk-dev] [PATCH v3 1/2] eal: add 128-bit cmpset (x86-64 only) Thread-Index: AQHUra7wYmJ+w7UMKEWkA1HXhAc3iqWy9AnAgAD6ulCAAI2KgA== Date: Fri, 18 Jan 2019 05:27:31 +0000 Message-ID: References: <20190115223232.31866-1-gage.eads@intel.com> <20190116151835.22424-1-gage.eads@intel.com> <20190116151835.22424-2-gage.eads@intel.com> <9184057F7FC11744A2107296B6B8EB1E541C8BCA@FMSMSX108.amr.corp.intel.com> In-Reply-To: <9184057F7FC11744A2107296B6B8EB1E541C8BCA@FMSMSX108.amr.corp.intel.com> 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=Honnappa.Nagarahalli@arm.com; x-originating-ip: [217.140.103.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM6PR08MB4263; 6:wPQ2s8sw61LiExS//1E+dpkCNkkYXQ/+mTzdowR3zIeEbNJN2alPFdvojGE1sTFMlJwaNRZX0GDFrKTZiVvGVlSqoYhwnIXOh/m4wnkOxKro3itMi3loWX9KInxzfbHjZFEYWRnhTkrjamp2S1Xvgw5RrucCjA4h0OEBmQM96PZc21R4PqYR+OHlxxit5eV+8voNFSfjm70DmxILdAovuV/q8RyGnwqFOa1jT4p5+O3gBMKkpH2E0yKxdV3Z7YLLXSFD7gU8JxS0R4hAiA8XaYhPXDmWk38kjRymgQl33bM03s69wa31TqLgTy5Prsm7dX++3UdObaJrkUN7bPQVKO+6xKEDGDXBU2E0vAeG+AMiJqbJvrQ9bXVH1+URZh8GU3p71JCZ+OigYqHbQxBzlWmG1JkRNSe9Soe9MBNtID9N8eJIbCbdhn5S/CQPz0prNvYeLxOd395If1IR46OMzg==; 5:BT/JQjofsR7kp8q6e1V6vrgdJyMAp2YvE8/MeHKXHRNKkGj8XwEfyKQGpw4TY/MAh5Pi4zkIbYhn5OlifdM7HLfJQFvyQO+ewRIqMU9vJpUcSvLDeOzKAQuSPShYND1pTkNIK93+9YMyLMPd6V9H2sHqQAm6uG18wukiFcLUvJModT2ludFbWLQxES26E4R90GDa+SlYZrMtHsElywCgfA==; 7:b06PCEUcgKV4c1s6LAO5NkC3CB/qYRAZAEqXdcfQpUQ9Bjy0lpJk9hdJPPtExQOPrMFxSFHW+hBuBnkwO3d7GdHqC2MCBOy46UmpTIz+bI0v1oaAmHn87EEmpWBhaDhoto6uOsm6rDQluApYtNIxHA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ceb4bdf6-4313-4672-c43d-08d67d05a518 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:AM6PR08MB4263; x-ms-traffictypediagnostic: AM6PR08MB4263: nodisclaimer: True x-microsoft-antispam-prvs: x-forefront-prvs: 0921D55E4F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(39860400002)(396003)(366004)(376002)(136003)(346002)(189003)(199004)(9686003)(74316002)(4326008)(7696005)(72206003)(55016002)(6306002)(305945005)(14444005)(229853002)(97736004)(476003)(25786009)(478600001)(106356001)(86362001)(105586002)(6246003)(53936002)(99286004)(14454004)(486006)(256004)(8676002)(446003)(81166006)(5660300001)(93886005)(2501003)(6436002)(6116002)(3846002)(11346002)(186003)(68736007)(110136005)(7736002)(2906002)(76176011)(71200400001)(316002)(81156014)(6506007)(26005)(54906003)(8936002)(102836004)(71190400001)(33656002)(966005)(66066001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB4263; H:AM6PR08MB3672.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: rrzdVbA7le0e1kv3wfI+1MgZNHbaFUbWezNZpaw38AUeom+bc6mVTb22VYyD81LpyCq9e6jPbJWka7wzul2nG013gUkFcrJbvjLXOWhf/294fwyT2aoDll0TeD+e7Thoom7JBZo2zUoXbNoPS/4bduvUqsZUgmcgcdju2vltUTuQkqLj/u7qbxpgJSNi8hu6VSXYxAsYLN2zVuVwq2t6CTcdee2hYNFponb8LWnkQJSJPX7tkMtMZyJ0WVmFC+Jiewtdn+zoXzdI9MOyf6oS1CxHVXlIKoHPPqdhvSmkN+lnJl050iktclZVzccxRYb8OJ26G9B7Qc+3tc5n7YVDryCWHQjYxBe/62e+FnQyC7QneDmePSHzy1uranLdpDkh+Bjit0vN2i8D0ZcUsBSdXs7+sFF7hAo8k44fnmbIfho= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: ceb4bdf6-4313-4672-c43d-08d67d05a518 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2019 05:27:31.7175 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4263 Subject: Re: [dpdk-dev] [PATCH v3 1/2] eal: add 128-bit cmpset (x86-64 only) 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: , X-List-Received-Date: Fri, 18 Jan 2019 05:27:33 -0000 > > > > > > This operation can be used for non-blocking algorithms, such as a > > > non- blocking stack or ring. > > > > > > Signed-off-by: Gage Eads > > > --- > > > .../common/include/arch/x86/rte_atomic_64.h | 22 > > > ++++++++++++++++++++++ > > > 1 file changed, 22 insertions(+) > > > > > > diff --git a/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h > > > b/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h > > > index fd2ec9c53..34c2addf8 100644 > > > --- a/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h > > > +++ b/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h > > Since this is a 128b operation should there be a new file created with > > the name rte_atomic_128.h? > > > > > @@ -34,6 +34,7 @@ > > > /* > > > * Inspired from FreeBSD src/sys/amd64/include/atomic.h > > > * Copyright (c) 1998 Doug Rabson > > > + * Copyright (c) 2019 Intel Corporation > > > * All rights reserved. > > > */ > > > > > > @@ -208,4 +209,25 @@ static inline void > > > rte_atomic64_clear(rte_atomic64_t > > > *v) } #endif > > > > > > +static inline int > > > +rte_atomic128_cmpset(volatile uint64_t *dst, uint64_t *exp, > > > +uint64_t > > > +*src) { > > The API name suggests it is a 128b operation. 'dst', 'exp' and 'src' > > should be pointers to 128b (__int128)? Or we could define our own data > type. >=20 > I agree, I'm not a big fan of the 64b pointers here. I avoided __int128 > originally because it fails to compile with -pedantic, but on second thou= ght > (and with your suggestion of a separate data type), we can resolve that w= ith > this typedef: >=20 > typedef struct { > RTE_STD_C11 __int128 val; > } rte_int128_t; ok >=20 > > Since, it is a new API, can we define it with memory orderings which > > will be more conducive to relaxed memory ordering based architectures? > > You can refer to [1] and [2] for guidance. >=20 > I certainly see the value in controlling the operation's memory ordering,= like in > the __atomic intrinsics, but I'm not sure this patchset is the right plac= e to > address that. I see that work going a couple ways: > 1. Expand the existing rte_atomicN_* interfaces with additional arguments= . In > that case, I'd prefer this be done in a separate patchset that addresses = all the > atomic operations, not just cmpset, so the interface changes are chosen > according to the needs of the full set of atomic operations. If this appr= oach is > taken then there's no need to solve this while rte_atomic128_cmpset is > experimental, since all the other functions are non-experimental anyway. >=20 > - Or - >=20 > 2. Don't modify the existing rte_atomicN_* interfaces (or their strongly > ordered behavior), and instead create new versions of them that take > additional arguments. In this case, we can implement rte_atomic128_cmpset= () > as is and create a more flexible version in a later patchset. >=20 > Either way, I think the current interface (w.r.t. memory ordering options= ) can > work and still leaves us in a good position for future changes/improvemen= ts. >=20 I do not see the need to modify/extend the existing rte_atomicN_* APIs as t= he corresponding __atomic intrinsics serve as replacements. I expect that a= t some point, DPDK code base will not be using rte_atomicN_* APIs. However, __atomic intrinsics do not support 128b wide parameters. Hence DPD= K needs to write its own. Since this is the first API in that regard, I pre= fer that we start with a signature that resembles __atomic intrinsics which= have been proven to provide best flexibility for all the platforms support= ed by DPDK. > > If this an external API, it requires 'experimental' tag. >=20 > Good catch -- will fix. >=20 > > > > 1. https://github.com/ARM- > > software/progress64/blob/master/src/lockfree/aarch64.h#L63 >=20 > I didn't know about aarch64's CASP instruction -- very cool! >=20 > > 2. https://github.com/ARM- > > software/progress64/blob/master/src/lockfree/x86-64.h#L34 > > > > > + uint8_t res; > > > + > > > + asm volatile ( > > > + MPLOCKED > > > + "cmpxchg16b %[dst];" > > > + " sete %[res]" > > > + : [dst] "=3Dm" (*dst), > > > + [res] "=3Dr" (res) > > > + : "c" (src[1]), > > > + "b" (src[0]), > > > + "m" (*dst), > > > + "d" (exp[1]), > > > + "a" (exp[0]) > > > + : "memory"); > > > + > > > + return res; > > > +} > > > + > > > #endif /* _RTE_ATOMIC_X86_64_H_ */ > > > -- > > > 2.13.6