From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <Honnappa.Nagarahalli@arm.com>
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 <dev@dpdk.org>; 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 <Honnappa.Nagarahalli@arm.com>
To: "Eads, Gage" <gage.eads@intel.com>, "dev@dpdk.org" <dev@dpdk.org>
CC: "olivier.matz@6wind.com" <olivier.matz@6wind.com>,
"arybchenko@solarflare.com" <arybchenko@solarflare.com>, "Richardson, Bruce"
<bruce.richardson@intel.com>, "Ananyev, Konstantin"
<konstantin.ananyev@intel.com>, nd <nd@arm.com>, nd <nd@arm.com>
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: <AM6PR08MB3672F8D8571B7258C5FF5B05989C0@AM6PR08MB3672.eurprd08.prod.outlook.com>
References: <20190115223232.31866-1-gage.eads@intel.com>
<20190116151835.22424-1-gage.eads@intel.com>
<20190116151835.22424-2-gage.eads@intel.com>
<AM6PR08MB36720B14933138607234687098830@AM6PR08MB3672.eurprd08.prod.outlook.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: <AM6PR08MB4263EF2714648EC081E9B557989C0@AM6PR08MB4263.eurprd08.prod.outlook.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=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 <gage.eads@intel.com>
> > > ---
> > > .../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