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 4794AA0471 for ; Fri, 19 Jul 2019 14:35:50 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id AF76E1B203; Fri, 19 Jul 2019 14:35:28 +0200 (CEST) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) by dpdk.org (Postfix) with ESMTP id 92B1E2C17 for ; Fri, 19 Jul 2019 14:35:26 +0200 (CEST) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x6JCZ8tP031712; Fri, 19 Jul 2019 05:35:22 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pfpt0818; bh=nMzqlyisCW0lliEEuKmKOLdxk22U6sU89K3At9ImIJs=; b=AydbGRnyCbn4tfE0Q1RiA1DjDVTGS4/ypOYSW9R30QxGTl82wOwmD+HfFHWj4EUJeszn tAf5HueVTnCtWSCYHDUkFv6+fLtbPVbdBuVNreAa0JtydgLTgbUfcDKuxaBJOMTCXjNY zr90eL37mqsCr3pVUC6tgsmF5xcjYR1XS/aHX6/rnb7TP0h+f4T0f5Q/cZdgdz7w/gEj Vm6MG/AuSqY4F14wSlzUAxDEoXu/evYgK5EnVygpTlAX91LBkpiOybbELmB4Xicjn6sK 3tsn86gCOYXMxNlGRxCOFPhDKU+uu2Va+pXpAx8xIjo1uqdOdoci0aPhZ1OvOYVsSeVp EQ== Received: from sc-exch03.marvell.com ([199.233.58.183]) by mx0a-0016f401.pphosted.com with ESMTP id 2ts07vsecd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 19 Jul 2019 05:35:22 -0700 Received: from SC-EXCH04.marvell.com (10.93.176.84) by SC-EXCH03.marvell.com (10.93.176.83) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 19 Jul 2019 05:35:21 -0700 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (104.47.33.58) by SC-EXCH04.marvell.com (10.93.176.84) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Fri, 19 Jul 2019 05:35:21 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SJ4Fx71IQAGipyma17kOIupWN8BYJL43uRol6zPnC2+QXG111BEMpIJKVvJB3WsAwb++TJrBq+IouJ3MyEGBniY/KHmG/b1Tk/NiIixq4al/X8Chtaxads1/khH4rdzEowz4ADfy0FTOYosAVYqfSKr+jDOS+fwvRuBAXUPhUE4qlHt51qzFVVNzpuP8zpt34Aw22D/QLgvf/neD/0X4ecam+zCWBbT14ZbKJAy180JSV48Qd/FQ8+52TwBYT1S46oAZTI1X6b3zQeEV2BgmjEGVS+4yOSeLPEh1R4SwXCRPUbu2HjSMPZTrbWRWwcO7avwOg1zjz8K3XTqM7eHS8w== 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=nMzqlyisCW0lliEEuKmKOLdxk22U6sU89K3At9ImIJs=; b=bTVSRdKa8VN67IHc0Jxhp41GgTnGkFbK/BEXO/UOAHKcTQDV8PD15HlVgkTfKbtN4HyCKAMuN/xmVPCEfVSdWdWHdfapZ6apg+Q4RtT6j9aStBmRla8Rd8JTHS+svqcWfHq3DXc5NOmlQOXGAiqtFSZ/rjRZ7t8V4ec+Ws01pqk8g+0AleZ7NDaQL6iCSWDsX7ebytMRSYbSrtst6kpeckxBOhA8SNGsrUIrnBlt7n+v1TingwKpWVMdCX2qDpmz6FSX8QwtvW594NbYIJAyiV+8pNfVPYmeNSNlY40Pxk8GXmtcnDTfpBilkaBvaBEdlDLfJObwhG54NmZLH7eqUQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=marvell.com;dmarc=pass action=none header.from=marvell.com;dkim=pass header.d=marvell.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector2-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nMzqlyisCW0lliEEuKmKOLdxk22U6sU89K3At9ImIJs=; b=FcVZpZcTpqDrUN/QL9b4cJoq1Fp8Cz7hvmRlMIVMvQA0keQBkk/LW4vtRjSNaSOZx8d8xy4mKkuPSke319MBDTHu1T65CCGN+4PJ1/XcaqcF2KDi2zTPpfb3b9m4V+2/rxdIHjb6igOv7vxoh8f+aMETt7+siW0igP8+spk8tLE= Received: from BYAPR18MB2424.namprd18.prod.outlook.com (20.179.91.149) by BYAPR18MB2566.namprd18.prod.outlook.com (20.179.93.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.14; Fri, 19 Jul 2019 12:35:19 +0000 Received: from BYAPR18MB2424.namprd18.prod.outlook.com ([fe80::2d42:12b6:aa2e:2862]) by BYAPR18MB2424.namprd18.prod.outlook.com ([fe80::2d42:12b6:aa2e:2862%4]) with mapi id 15.20.2073.012; Fri, 19 Jul 2019 12:35:18 +0000 From: Jerin Jacob Kollanukkaran To: "Phil Yang (Arm Technology China)" , "dev@dpdk.org" CC: "thomas@monjalon.net" , "hemant.agrawal@nxp.com" , Honnappa Nagarahalli , "Gavin Hu (Arm Technology China)" , nd , "gage.eads@intel.com" , nd Thread-Topic: [EXT] [PATCH v3 1/3] eal/arm64: add 128-bit atomic compare exchange Thread-Index: AQHVLYk2hpq4OasZX0+HEFxbT7xNTqbRjN6AgABaqQCAABNd0A== Date: Fri, 19 Jul 2019 12:35:18 +0000 Message-ID: References: <1561257671-10316-1-git-send-email-phil.yang@arm.com> <1561709503-11665-1-git-send-email-phil.yang@arm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [106.200.248.176] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b9c054ba-399e-400f-57f5-08d70c458f22 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR18MB2566; x-ms-traffictypediagnostic: BYAPR18MB2566: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01039C93E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(366004)(396003)(136003)(39860400002)(189003)(199004)(74316002)(305945005)(7736002)(81156014)(66066001)(8936002)(81166006)(2501003)(2906002)(6246003)(6306002)(53936002)(4326008)(9686003)(6436002)(55016002)(8676002)(229853002)(68736007)(486006)(256004)(86362001)(25786009)(14444005)(110136005)(966005)(54906003)(5660300002)(99286004)(7696005)(102836004)(26005)(446003)(76176011)(186003)(476003)(11346002)(6506007)(316002)(76116006)(66946007)(478600001)(14454004)(33656002)(6116002)(52536014)(3846002)(66446008)(66476007)(66556008)(71200400001)(71190400001)(64756008); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB2566; H:BYAPR18MB2424.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: marvell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: f4YoLR7HHGeckUaIg0SJlyzPNrZ7a2LN4NjsCBqORdoPnpZXQLjsJLMoBfDKzygGLyvWkAmbSZZSbjXEfL+O23EAEbAQkIrxJV8j77HR3/J0GxMrlYPKZJmQGmAbr7VpV6H9VGz7WoNU2S15CVgiqr7bgE1jzYNi7zAp4eU06kiq+3WfHKcYU24LzuGEDP4RpInTGv31nnDznDzAkrAm+WMZZvy9u/rHxcNT5XJu3Hcd+WpZMsZvsZQAN87M20aazkoY8Fsw6qXh8hmKYwD6AoFOVgKfRjZyX3Jqk181D4AEFju2IzaUiOC5PQ7c2dMPRN3FdS5pVVn620NUidWdBz8gpgyhVU/XackAeArSJFgknidpi5ueE92ibzGhf8WukXQiOtf6DVYFv0iAC2R5V4l3i8uuKyuWE4sjDAOSjxs= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b9c054ba-399e-400f-57f5-08d70c458f22 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2019 12:35:18.7515 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jerinj@marvell.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2566 X-OriginatorOrg: marvell.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-07-19_09:2019-07-19,2019-07-19 signatures=0 Subject: Re: [dpdk-dev] [EXT] [PATCH v3 1/3] eal/arm64: add 128-bit atomic compare exchange 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" > > > +#define RTE_HAS_ACQ(mo) ((mo) !=3D __ATOMIC_RELAXED && (mo) !=3D > > > +__ATOMIC_RELEASE) #define RTE_HAS_RLS(mo) ((mo) =3D=3D > > > __ATOMIC_RELEASE || \ > > > + (mo) =3D=3D __ATOMIC_ACQ_REL || \ > > > + (mo) =3D=3D __ATOMIC_SEQ_CST) > > > + > > > +#define RTE_MO_LOAD(mo) (RTE_HAS_ACQ((mo)) \ > > > + ? __ATOMIC_ACQUIRE : __ATOMIC_RELAXED) #define > > > RTE_MO_STORE(mo) > > > +(RTE_HAS_RLS((mo)) \ > > > + ? __ATOMIC_RELEASE : __ATOMIC_RELAXED) > > > + > > > > The one starts with RTE_ are public symbols, If it is generic enough, > > Move to common layer so that every architecturse can use. > > If you think, otherwise make it internal >=20 > Let's keep it internal. I will remove the 'RTE_' tag. Probably change to __HAS_ACQ to avoid collision(just in case) > > > > > > > > > +#ifdef __ARM_FEATURE_ATOMICS > > > > This define is added in gcc 9.1 and I believe for clang it is not suppo= rted yet. > > So old gcc and clang this will be undefined. > > I think, With meson + native build, we can find the presence of > > ATOMIC support by running a.out. Not sure about make and cross build ca= se. > > I don't want block this feature because of this, IMO, We can add this > > code with existing __ARM_FEATURE_ATOMICS scheme and later find a > > method to enhance it. But please check how to fix it. >=20 > OK. After thinking on this a bit, I think, in order to support old gcc(< gcc 9= .1) and clang, We can introduce a config option, where, by default it is disabled and enab= le In specific config(where we know, lse is supported) and meson config. i.e #if defined(__ARM_FEATURE_ATOMICS) || defined(RTE_ARM_FEATURE_ATOMICS) >=20 > > > > > +#define __ATOMIC128_CAS_OP(cas_op_name, op_string) = \ > > > +static inline rte_int128_t = \ > > > +cas_op_name(rte_int128_t *dst, rte_int128_t old, = \ > > > + rte_int128_t updated) = \ > > > +{ = \ > > > + /* caspX instructions register pair must start from even-numbered > > > + * register at operand 1. > > > + * So, specify registers for local variables here. > > > + */ = \ > > > + register uint64_t x0 __asm("x0") =3D (uint64_t)old.val[0]; = \ > > > > Since direct x0 register used in the code and > > cas_op_name() and rte_atomic128_cmp_exchange() is inline function, > > Based on parent function load, we may corrupt x0 register aka >=20 > Since x0/x1 and x2/x3 are used a lot and often contain live values. > Maybe to change them to some relatively less frequently used registers li= ke > x14/x15 and x16/x17 might help for this case? > According to the PCS (Procedure Call Standard), x14-x17 are also temporar= y > registers. X14-x17 are temporary registers but since=20 cas_op_name() and rte_atomic128_cmp_exchange() are inline functions, Based on the parent function register usage, it _may_ corrupt. >=20 > > Break arm64 ABI. Not sure clobber list will help here or not? >=20 > In my understanding, for the register variable, if it contains a live val= ue in the > specified register, the compiler will move the live value into a free reg= ister. > Since x0~x3 are present in the input/output operands and x0/x1's value ne= eds to > be restored to the variable 'old' as a return value. > So I didn't add them into the clobber list. OK >=20 > > Making it as no_inline will help but not sure about the performance imp= act. > > May be you can check with compiler team. > > > > We burned our hands with this scheme, see > > 5b40ec6b966260e0ff66a8a2c689664f75d6a0e6 ("mempool/octeontx2: fix > > possible arm64 ABI break") > > > > Probably we can choose a scheme for rc2 and adjust as when we have > > complete clarity. > > > > > > > > +#if defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_ARM64) > > > > There is nothing specific to x86 and arm64 here, Can we remove this #if= def ? >=20 > Without this constraint, it will break 32-bit x86 builds. > http://mails.dpdk.org/archives/test-report/2019-June/086586.html OK . #ifdef RTE_ARCH_64 would help then. >=20 > > > > > +/** > > > + * 128-bit integer structure. > > > + */ > > > +RTE_STD_C11 > > > +typedef struct { > > > + RTE_STD_C11 > > > + union { > > > + uint64_t val[2]; > > > + __extension__ __int128 int128; Instead of guarding RTE_ARCH_64 on this complete structure, How about it only under #ifdef RTE_ARCH_64 __extension__ __int128 int128; #endif So that it rte_int128_t will be available for 32bit as well. > > > + }; > > > +} __rte_aligned(16) rte_int128_t; > > > +#endif > > > + > > > #ifdef __DOXYGEN__