From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130057.outbound.protection.outlook.com [40.107.13.57]) by dpdk.org (Postfix) with ESMTP id 24D26DE3 for ; Tue, 22 Jan 2019 21:30:35 +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=/1/7Kkq42QOySw6+NuBSTg3jFdXoc9AcENz5oFCF1B4=; b=ZMJ6gnGoEkI/Zp/eMzXsxEbzEn4OtQlR4s/0U56vI4x2yvClY2kwI5E3J5mA+f+vr1FZ8r60PdoGGfhy6r7Bh+2aojov4bFhZadWAi7owPwjGnhp8J/LHtrTKIf6OLsVRupo0rm5frGuIrNrDL+KBr/priA/sOrKZJF9dT+59Jw= Received: from AM6PR08MB3672.eurprd08.prod.outlook.com (20.177.115.76) by AM6PR08MB2999.eurprd08.prod.outlook.com (52.135.163.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1537.29; Tue, 22 Jan 2019 20:30:34 +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.031; Tue, 22 Jan 2019 20:30:34 +0000 From: Honnappa Nagarahalli To: "Eads, Gage" , "dev@dpdk.org" CC: "olivier.matz@6wind.com" , "arybchenko@solarflare.com" , "Richardson, Bruce" , "Ananyev, Konstantin" , nd , "chaozhu@linux.vnet.ibm.com" , "jerinj@marvell.com" , "hemant.agrawal@nxp.com" , nd Thread-Topic: [dpdk-dev] [PATCH v3 1/2] eal: add 128-bit cmpset (x86-64 only) Thread-Index: AQHUra7wYmJ+w7UMKEWkA1HXhAc3iqWy9AnAgAD6ulCAAI2KgIABGauAgAYqIlA= Date: Tue, 22 Jan 2019 20:30:34 +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> <9184057F7FC11744A2107296B6B8EB1E541C94D9@FMSMSX108.amr.corp.intel.com> In-Reply-To: <9184057F7FC11744A2107296B6B8EB1E541C94D9@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.111.135] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM6PR08MB2999; 6:gr1Ua59+KWTljQqxznRO7/5V+OAfzv8tw+S1D7G/rWj0sziqeqPcWjg0qMkHWim4Yv7SL62eGWxWLh3eJEcZ7iV+eSUKcfnBLKPOH2tRw8iJtApOPRM2J4GOgpjUabfAuJAjPg6dTIjVcfmcGFU2XJMeGEEPydB9SSUymZM9yGpdjwTqYiLl1zkDBuComFMWzUAKW2bJ2A09zJFFczNJlvlS7l5dosF+45ocaNaomznkcbe8Al+sqKbDZGVEgR+28aw1MP0O5rBqcpHjreQMzfRqOkB07lmrlFFBetzlseMBZ5IuAUE8WpJL5pkMnK5bo/WwEUlzBuH+yhj2Zd5RfVE3Y1x21K8O5hJ81Aq1MKnZ77qCKH7oCmk1aIF/x7rdUFGaKOAExgttXvZyVA3Oz1BoALj9jkcVW+LHsX83Z79udCsGwcpHjd0WGUSQxZC4RMp4ys07kQiqCN+AhOOotw==; 5:avG7D4XKAyYCc3St/hFhBu6bKC5i86X+NlT2VIo9U9HzjszRmGZU9Co4Y+J3yN070OEzG0ni94v/1APHdDi/HIPo/VbAWH4uh5OkRNt7bshoMqXC+bo0W5nJMhNynJgwbWJfiKXcLfpb5gs6/krNzJA1+gNWq8OVoYFOPwRRZXI9hNJ/jaCCrCzD7Ar5K79wwPwk6290JGqTF4S3q2qTXg==; 7:3UEtrHNiZsfCmoP9YBByC/s7Ur5OePiuWAtR+yshU6iRd3p/f/6tWlhUI4bd3oJ/TMu713MVvxIZuLJj0oFQY4UMqA9FycD4zVWFdKKc2Yubr+QqXC3ql+MgY8GwgtdYhilH4DQ6TneRtyr8/nIYsw== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: e7946b74-814c-4769-c2a9-08d680a8765e 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:AM6PR08MB2999; x-ms-traffictypediagnostic: AM6PR08MB2999: x-ld-processed: f34e5979-57d9-4aaa-ad4d-b122a662184d,ExtAddr nodisclaimer: True x-microsoft-antispam-prvs: x-forefront-prvs: 0925081676 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(346002)(366004)(396003)(136003)(189003)(199004)(54906003)(26005)(256004)(102836004)(14444005)(76176011)(86362001)(6246003)(476003)(66066001)(99286004)(316002)(6506007)(68736007)(186003)(7696005)(110136005)(74316002)(7736002)(305945005)(486006)(81166006)(8676002)(81156014)(2906002)(8936002)(6436002)(97736004)(71200400001)(71190400001)(446003)(93886005)(14454004)(33656002)(72206003)(229853002)(966005)(9686003)(105586002)(6306002)(25786009)(106356001)(11346002)(6116002)(3846002)(4326008)(2501003)(53936002)(478600001)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB2999; 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: P6YxAM6awG5KmQQHXE4xDrMiDxuiWfo17vdgwrDjii6MRBz/EHzjPsihQRIKXnpCgjjSDJVrFfQ33IaiVZzxByGNaMGyv/S2ENDBndnFJ7cLYpG+ZYJhhoZ38C6IdqSYdznEw3oGTjPSNakNyGFIRB2B6uX2MjHDm58m3yNylwRy4CROBQWc2biCz3rDTMLIP3fHyGkOLnWtktZlt7xBQxrTzeiopV5qcVVaZfcxuV9jXkikFy0qPX2/gF8kAZ4sZPD5uteU8G0Vg9espUaal7gE950ntlKyNt6ufAJ1vADX1lM/WLd8aIvagc+SmCKq/y6OgWTbfXag9ZTac6ZVq+hCizprT5alPAzycgV4thReyjKwZQB9K0EdljL0Nx+85RDomRaknSvehJVueL/oT4iu1kDDwxApzenFgIsQAfA= 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: e7946b74-814c-4769-c2a9-08d680a8765e X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2019 20:30:34.6785 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB2999 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: Tue, 22 Jan 2019 20:30:36 -0000 Added other platform owners. > > > > > @@ -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. > > > > > > 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 thought (and with your suggestion of a separate data > > > type), we can resolve that with this typedef: > > > > > > typedef struct { > > > RTE_STD_C11 __int128 val; > > > } rte_int128_t; > > ok > > > > > > > > > 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. > > > > > > 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 place 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 approach 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. > > > > > > - Or - > > > > > > 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. > > > > > > 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/improvements. > > > > > I do not see the need to modify/extend the existing rte_atomicN_* APIs > > as the corresponding __atomic intrinsics serve as replacements. I > > expect that at some point, DPDK code base will not be using > rte_atomicN_* APIs. > > However, __atomic intrinsics do not support 128b wide parameters. > > Hence >=20 > I don't think that's correct. From the GCC docs: >=20 > "16-byte integral types are also allowed if `__int128' (see __int128) is > supported by the architecture." >=20 > This works with x86 -64 -- I assume aarch64 also, but haven't confirmed. >=20 > Source: https://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/_005f_005fatomic- > Builtins.html (following is based on my reading, not based on experiments) My understanding is that the __atomic_load_n/store_n were implemented using= a compare-and-swap HW instruction (due to lack of HW 128b atomic load and = store instructions). This introduced the side effect or store/load respecti= vely. Where as the user does not expect such side effects. As suggested in = [1], it looks like GCC delegated the implementation to libatomic which 'it = seems' uses locks to implement 128b __atomic intrinsics (needs to be verifi= ed) If __atomic intrinsics, for any of the supported platforms, do not have an = optimal implementation, I prefer to add a DPDK API as an abstraction. A giv= en platform can choose to implement such an API using __atomic intrinsics i= f it wants. The DPDK API can be similar to __atomic_compare_exchange_n. [1] https://patchwork.ozlabs.org/patch/721686/ [2] https://gcc.gnu.org/ml/gcc/2017-01/msg00167.html >=20 > > DPDK needs to write its own. Since this is the first API in that > > regard, I prefer that we start with a signature that resembles > > __atomic intrinsics which have been proven to provide best flexibility = for > all the platforms supported by DPDK.