From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 3D3E641C5B; Fri, 10 Feb 2023 06:30:25 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2696240EE6; Fri, 10 Feb 2023 06:30:25 +0100 (CET) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2065.outbound.protection.outlook.com [40.107.20.65]) by mails.dpdk.org (Postfix) with ESMTP id 86B8540EE3; Fri, 10 Feb 2023 06:30:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KCZQMKR+faZfZFF5P3cJgIRoWXMVmiVFCZ2BvMzXpxc=; b=P37cbmCm7uTl64+m9haBxr/QsEM20996zfnsNje6FF9CeHt2HpBNqZUHqzhzwq4JfwBuN/XUQvnlSGt4y/C3SZ9dCjtQ38Pt6pV218Y9MN1/Rbk2O3GG3NXJsApXLlsQ10WVGwyHGOQMYPdahCu/oBe+KtTvVd/6edw95ZZRSNA= Received: from DU2PR04CA0259.eurprd04.prod.outlook.com (2603:10a6:10:28e::24) by GV1PR08MB8059.eurprd08.prod.outlook.com (2603:10a6:150:95::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6086.21; Fri, 10 Feb 2023 05:30:10 +0000 Received: from DBAEUR03FT012.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:28e:cafe::27) by DU2PR04CA0259.outlook.office365.com (2603:10a6:10:28e::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6086.21 via Frontend Transport; Fri, 10 Feb 2023 05:30:10 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DBAEUR03FT012.mail.protection.outlook.com (100.127.142.126) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6086.19 via Frontend Transport; Fri, 10 Feb 2023 05:30:10 +0000 Received: ("Tessian outbound b1d3ffe56e73:v132"); Fri, 10 Feb 2023 05:30:09 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: c48f3c01605f6dd3 X-CR-MTA-TID: 64aa7808 Received: from e6ca0b3a42f9.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 0A8A7681-087A-4413-B0B2-CCEC61B1721E.1; Fri, 10 Feb 2023 05:30:03 +0000 Received: from EUR01-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id e6ca0b3a42f9.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 10 Feb 2023 05:30:03 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KRwo1iSrZ+TQic0bLtKKH3O1JX80nd5dtuk6K0pva/MKiia4WVNfiFo6EeyZATIp6t5HIdEL1xZrRo/ZQd5MCv1sqgVuFesAmUOfZlKG4mvW5lejBf2ENW0SDj9gpvokKOxE2T64ut078EIt/uPaOvMBjmL4gbzLbjM7vMIwtkMlQtme3Z04fmrQqrdqK6NLEoviyNCam0SHMHQuxScH6lKIsXVefQlw9kxs5j5uRm1I8Ta84SKrNTaCybTK5bL4t8d+Gd6QmDey6t2A9NLD1qYkRM6T/M0DclTgHV0MFEI0FvHMPYx+Yz5Ru/lI9o9JCS6naNvM3fEkaLAfB2JwiA== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KCZQMKR+faZfZFF5P3cJgIRoWXMVmiVFCZ2BvMzXpxc=; b=O6dIjTagFONHmQ0Zr+/H5FBCIN+GWOorEjjm6Eo7TcsXzkd5W+J1TqFfFUhCrH+MiloOvZ4oqrAbv/p1aMP/6wI+5oF5TA0CnxTACZ/I/IzDgk18AkQNQ+KR3zNq6gTobVTpNwFJYUxSclBkbyBl2Z3QmFl4mKNCSGP9ReliYI5Ypp4yew/FLKk9I/5QLjv/aQjxYF3anGQyyo7mRVAVgYdqRIzbHhlOxNhizF6AtmnSwuLPNhOUwGOmrELKfLi+h7oztCgSM2SQ0EfOHTme5+dt0DmPxDIw9HB1itehFVgRihLb+mzEvCp5XwXbObWEgHczceBdmbl2puIT/VHzIw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KCZQMKR+faZfZFF5P3cJgIRoWXMVmiVFCZ2BvMzXpxc=; b=P37cbmCm7uTl64+m9haBxr/QsEM20996zfnsNje6FF9CeHt2HpBNqZUHqzhzwq4JfwBuN/XUQvnlSGt4y/C3SZ9dCjtQ38Pt6pV218Y9MN1/Rbk2O3GG3NXJsApXLlsQ10WVGwyHGOQMYPdahCu/oBe+KtTvVd/6edw95ZZRSNA= Received: from DBAPR08MB5814.eurprd08.prod.outlook.com (2603:10a6:10:1b1::6) by AS8PR08MB10292.eurprd08.prod.outlook.com (2603:10a6:20b:62b::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6064.34; Fri, 10 Feb 2023 05:30:00 +0000 Received: from DBAPR08MB5814.eurprd08.prod.outlook.com ([fe80::f8c8:b4b6:c041:ac9d]) by DBAPR08MB5814.eurprd08.prod.outlook.com ([fe80::f8c8:b4b6:c041:ac9d%7]) with mapi id 15.20.6086.019; Fri, 10 Feb 2023 05:30:00 +0000 From: Honnappa Nagarahalli To: Tyler Retzlaff CC: =?iso-8859-1?Q?Morten_Br=F8rup?= , "thomas@monjalon.net" , "dev@dpdk.org" , "bruce.richardson@intel.com" , "david.marchand@redhat.com" , "jerinj@marvell.com" , "konstantin.ananyev@huawei.com" , "ferruh.yigit@amd.com" , nd , "techboard@dpdk.org" , nd Subject: RE: [PATCH] eal: introduce atomics abstraction Thread-Topic: [PATCH] eal: introduce atomics abstraction Thread-Index: AQHZNcVOKaGjm++r5EuVscptDtirzq65Kg2ggAF2NYCAAAyiAIAJnq4AgAB4YgCAAIctgIAAZAUAgAE9qYCAAMOQMA== Date: Fri, 10 Feb 2023 05:30:00 +0000 Message-ID: References: <1673558785-24992-1-git-send-email-roretzla@linux.microsoft.com> <1673558785-24992-2-git-send-email-roretzla@linux.microsoft.com> <1844463.CQOukoFCf9@thomas> <20230201214111.GA30564@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <20230208012040.GA22219@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <98CBD80474FA8B44BF855DF32C47DC35D8770D@smartserver.smartshare.dk> <20230208163521.GB5117@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> <20230209173017.GA21854@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> In-Reply-To: <20230209173017.GA21854@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: BCC31C999C90C94AA964509BB2DDD0C9.0 Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: DBAPR08MB5814:EE_|AS8PR08MB10292:EE_|DBAEUR03FT012:EE_|GV1PR08MB8059:EE_ X-MS-Office365-Filtering-Correlation-Id: bd6d7448-8cef-48e2-5955-08db0b27e077 x-ld-processed: f34e5979-57d9-4aaa-ad4d-b122a662184d,ExtAddr x-checkrecipientrouted: true nodisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 9RrYnCs/dkxYEyWYUNkP+j1dXocfyss2SHg33Rbqhbn7+GnpgpdurOxejtW5NFYpFBq6FV5DDFkwWksQZuOa0nJV9Ij8VikxcH8nDIWw1ImvdLe6NGSUQqo4jz8FfnvCHnZ9pzfizKd/7Wr7k4F42r/k80o6TBfWxJ5dpopXgcqrWw0JBk7njG8Lzfs86QAGe8CjmW/RNPVF9rTLiiAVtrCqx0iB9H7CnnS3Pu169ue9HJUmkEIkcKDV8Ya+RJKOXmYeP8owM1bdoiwxkOVKhW4+eJIgagBiBAmMvDQfNIM244RsT9UXCw42/c8pCCfW4pFgEBQ0XlD3n3LUnpho7xMGb35G5+Zp+gU4M1q+BbpK9ePnWKHrIeGci55ekxBmOWvgPh7nJUzptNeAxl8XNkT1nQK87X6TSsJinqrw9MxWmMRoWQrlvqgPF5BWs5OFjwCoPsTku1Eft5sVlK6p+HRXxOAPGuv7yWBbDPE1cGLuWYCqbQeWmAsV4AntbNf/dcXyGiXboCNvqkp3irFcQDk+pOXrCK0fTKHJFc+aMOx6vGkHVOR6LJ7D4p61jK2v9ekZbyBQLEMDtG6zYaf51bXp1MQ25wzJqwO7uUj2Cxq0CxTFpg/bhoBTs2xw2WuS0YBCRLhzjgw65PW5AY5ahRs/maCUppQbT0N6qMi2sF86Yh0P0n69vxPIIvSe5wjer+Pl4mhdQLmho4fjn2/9K1E8pVv/+ymn3R55d1BJIsNf4m/7ySMZHC6XnQTxnjgA3y3G/UjBKHvFyi5qScxudoId7Xi4slb+FMeO1JBD4Cc= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DBAPR08MB5814.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230025)(4636009)(366004)(136003)(39860400002)(376002)(346002)(396003)(451199018)(2906002)(38070700005)(122000001)(7416002)(8936002)(38100700002)(30864003)(6506007)(5660300002)(52536014)(4326008)(41300700001)(54906003)(6916009)(66946007)(86362001)(76116006)(83380400001)(8676002)(55016003)(316002)(33656002)(7696005)(9686003)(66446008)(71200400001)(186003)(478600001)(66476007)(66556008)(966005)(64756008)(21314003); DIR:OUT; SFP:1101; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB10292 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DBAEUR03FT012.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: dd11515f-4b1c-49f9-7297-08db0b27da94 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: k2BLSuTR4+2tAEZlBIMwCTyRE9KFUKon1U3aLBYSzZqsi37MpoQfLkXrZi6IPi19nxdJmTMpXbmz9o/BWa9XZYikSExrDB0u1YDMklYVHIRet2D8xx2IM7YeXY0bRRY3wURpN4PdcIpDCzsXpf/rWg4NP7dRrwcjguoAwJPOA2SNttbnUWoa6aJsuJgsnLGtrifHD9ceGZ12ZhVXJbvEwCnsB+cbIykG6buQyIpsOoAKcFBcUFLY18t2mPUADyW3HPfqd12MWjJPKi+Sn772TfqbPWUpPTihQ5/aCdrKhfNMIHoHPBgCb7FFi+lIGmdvEObuf1u2U6juwtto6rQIOT8LRAlr92+/PgzcuFV9kkku3G8hGJ34Dk0YeApdXPUm+YwVWTwizrIBdPNsrkh5ZhBL/TKsKWi2OGYZqs5Wh8TtuuvKHwvSlap8A2N2JZLHxRSBCIl9967KJ++7EAuXAftZdSg0zcVtJ9TuafQZlJtc7z25R/WzszozwhK0HRsYUBs5Pj1pRPuRKdZDYBFlAukr7QkiNaJb8WfZKOUWO1oxEHYwf3lSvQsEL4mRejLiaZzIwDyzaIpUfB5lW0WglPajurigu+1oMRxLUeX+sGA7lDgiFzLk39MbKVq3P5rRXp0FDjEywilpD2VIMVLKj+kiqrlILMqc/2T7Y0JPn+qA30m1WEuLLsvlhztZAtj4/DhFoO36wkW1p+qi7jf4BxPkTHcgKt6PgV+JfQra+Az41+pzKlTfhZSClt9utp3tX2mKet9FRfmnI0CIYIDaf3GezsDYqmpI9SLb3x45CbA= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(13230025)(4636009)(376002)(39860400002)(396003)(346002)(136003)(451199018)(46966006)(36840700001)(40470700004)(81166007)(356005)(33656002)(86362001)(82740400003)(5660300002)(70206006)(36860700001)(52536014)(41300700001)(8936002)(70586007)(6862004)(316002)(54906003)(450100002)(4326008)(8676002)(40480700001)(40460700003)(82310400005)(55016003)(30864003)(2906002)(47076005)(336012)(83380400001)(478600001)(966005)(7696005)(186003)(26005)(6506007)(9686003)(21314003); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Feb 2023 05:30:10.0605 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: bd6d7448-8cef-48e2-5955-08db0b27e077 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DBAEUR03FT012.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV1PR08MB8059 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org > On Thu, Feb 09, 2023 at 12:16:38AM +0000, Honnappa Nagarahalli wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > For environments where stdatomics are not supported, we > > > > > > > > could > > > > > have a > > > > > > > stdatomic.h in DPDK implementing the same APIs (we have to > > > > > > > support > > > > > only > > > > > > > _explicit APIs). This allows the code to use stdatomics APIs > > > > > > > and > > > > > when we move > > > > > > > to minimum supported standard C11, we just need to get rid > > > > > > > of the > > > > > file in DPDK > > > > > > > repo. > > > > > > > > > > > > > > my concern with this is that if we provide a stdatomic.h or > > > > > introduce names > > > > > > > from stdatomic.h it's a violation of the C standard. > > > > > > > > > > > > > > references: > > > > > > > * ISO/IEC 9899:2011 sections 7.1.2, 7.1.3. > > > > > > > * GNU libc manual > > > > > > > > > > > > > > https://www.gnu.org/software/libc/manual/html_node/Reserved- > > > > > > > Names.html > > > > > > > > > > > > > > in effect the header, the names and in some instances > > > > > > > namespaces > > > > > introduced > > > > > > > are reserved by the implementation. there are several > > > > > > > reasons in > > > > > the GNU libc > > > > > > Wouldn't this apply only after the particular APIs were introdu= ced? > > > > > i.e. it should not apply if the compiler does not support stdatom= ics. > > > > > > > > > > yeah, i agree they're being a bit wishy washy in the wording, > > > > > but i'm not convinced glibc folks are documenting this as > > > > > permissive guidance against. > > > > > > > > > > > > > > > > > > manual that explain the justification for these reservations > > > > > > > and if > > > > > if we think > > > > > > > about ODR and ABI compatibility we can conceive of others. > > > > > > > > > > > > > > i'll also remark that the inter-mingling of names from the > > > > > > > POSIX > > > > > standard > > > > > > > implicitly exposed as a part of the EAL public API has been > > > > > problematic for > > > > > > > portability. > > > > > > These should be exposed as EAL APIs only when compiled with a > > > > > compiler that does not support stdatomics. > > > > > > > > > > you don't necessarily compile dpdk, the application or its other > > > > > dynamically linked dependencies with the same compiler at the > > > > > same time. > > > > > i.e. basically the model of any dpdk-dev package on any linux > > > > > distribution. > > > > > > > > > > if dpdk is built without real stdatomic types but the > > > > > application has to interoperate with a different kit or library > > > > > that does they would be forced to dance around dpdk with their > > > > > own version of a shim to hide our faked up stdatomics. > > > > > > > > > > > > > So basically, if we want a binary DPDK distribution to be > > > > compatible with a > > > separate application build environment, they both have to implement > > > atomics the same way, i.e. agree on the ABI for atomics. > > > > > > > > Summing up, this leaves us with only two realistic options: > > > > > > > > 1. Go all in on C11 stdatomics, also requiring the application > > > > build > > > environment to support C11 stdatomics. > > > > 2. Provide our own DPDK atomics library. > > > > > > > > (As mentioned by Tyler, the third option - using C11 stdatomics > > > > inside DPDK, and requiring a build environment without C11 > > > > stdatomics to implement a shim - is not realistic!) > > > > > > > > I strongly want atomics to be available for use across inline and > > > > compiled > > > code; i.e. it must be possible for both compiled DPDK functions and > > > inline functions to perform atomic transactions on the same atomic va= riable. > > > > > > i consider it a mandatory requirement. i don't see practically how > > > we could withdraw existing use and even if we had clean way i don't > > > see why we would want to. so this item is defintely settled if you we= re > concerned. > > I think I agree here. > > > > > > > > > > > > > So either we upgrade the DPDK build requirements to support C11 > > > > (including > > > the optional stdatomics), or we provide our own DPDK atomics. > > > > > > i think the issue of requiring a toolchain conformant to a specific > > > standard is a separate matter because any adoption of C11 standard > > > atomics is a potential abi break from the current use of intrinsics. > > I am not sure why you are calling it as ABI break. Referring to [1], I = just see > wrappers around intrinsics (though [2] does not use the intrinsics). > > > > [1] > > https://github.com/gcc-mirror/gcc/blob/master/gcc/ginclude/stdatomic.h > > [2] > > https://github.com/llvm-mirror/clang/blob/master/lib/Headers/stdatomic > > .h >=20 > it's a potential abi break because atomic types are not the same types as= their > corresponding integer types etc.. (or at least are not guaranteed to be b= y all > implementations of c as an abstract language). >=20 > ISO/IEC 9899:2011 >=20 > 6.2.5 (27) > Further, there is the _Atomic qualifier. The presence of the _Atomic > qualifier designates an atomic type. The size, representation, and al= ignment > of an atomic type need not be the same as those of the corresponding > unqualified type. >=20 > 7.17.6 (3) > NOTE The representation of atomic integer types need not have the sam= e size > as their corresponding regular types. They should have the same size > whenever > possible, as it eases effort required to port existing code. >=20 > i use the term `potential abi break' with intent because for me to assert= in > absolute terms i would have to evaluate the implementation of every curre= nt > and potential future compilers atomic vs non-atomic types. this as i'm su= re you > understand is not practical, it would also defeat the purpose of moving t= o a > standard. therefore i rely on the specification prescribed by the standar= d not > the detail of a specific implementation. Can we say that the platforms 'supported' by DPDK today do not have this pr= oblem? Any future platforms that will come to DPDK have to evaluate this. >=20 >=20 > > > the abstraction (whatever namespace it resides) allows the existing > > > toolchain/platform combinations to maintain compatibility by > > > defaulting to current non-standard intrinsics. > > How about using the intrinsics (__atomic_xxx) name space for abstractio= n? > This covers the GCC and Clang compilers. >=20 > the namespace starting with `__` is also reserved for the implementation. > this is why compilers gcc/clang/msvc place name their intrinsic and built= in > functions starting with __ to explicitly avoid collision with the applica= tion > namespace. Agreed. But, here we are considering '__atomic_' specifically (i.e. not jus= t '__') >=20 > ISO/IEC 9899:2011 >=20 > 7.1.3 (1) > All identifiers that begin with an underscore and either an uppercase > letter or another underscore are always reserved for any use. >=20 > ... >=20 > > If there is another platform that uses the same name space for somethin= g > else, I think DPDK should not be supporting that platform. >=20 > that's effectively a statement excluding windows platform and all non-gcc > compilers from ever supporting dpdk. Apologies, I did not understand your comment on windows platform. Do you me= an to say a compiler for windows platform uses '__atomic_xxx' name space to= provide some other functionality (and hence it would get excluded)?=20 Clang supports these intrinsics. I am not sure about the merit of supportin= g other non-gcc compilers. May be a topic Techboard discussion. >=20 > > What problems do you see? >=20 > i'm fairly certain at least one other compiler uses the __atomic namespac= e but Do you mean __atomic namespace is used for some other purpose? > it would take me time to check, the most notable potential issue that com= es to > mind is if such an intrinsic with the same name is provided in a differen= t > implementation and has either regressive code generation or different > semantics it would be bad because it is intrinsic you can't just hack aro= und it > with #undef __atomic to shim in a semantically correct version. I do not think we should worry about regressive code generation problem. It= should be fixed by that compiler. Different semantics is something we need to worry about. It would be good t= o find out more about a compiler that does this. >=20 > how about this, is there another possible namespace you might suggest tha= t > conforms or doesn't conflict with the the rules defined in ISO/IEC 9899:2= 011 > 7.1.3 i think if there were that would satisfy all of my concerns related= to > namespaces. >=20 > keep in mind the point of moving to a standard is to achieve portability = so if we > do things that will regress us back to being dependent on an implementati= on > we haven't succeeded. that's all i'm trying to guarantee here. Agree. We are trying to solve a problem that is temporary. I am trying to k= eep the problem scope narrow which might help us push to adopt the standard= sooner. >=20 > i feel like we are really close on this discussion, if we can just iron t= his issue out > we can probably get going on the actual changes. >=20 > thanks for the consideration. >=20 > > > > > > > > once in place it provides an opportunity to introduce new > > > toolchain/platform combinations and enables an opt-in capability to > > > use stdatomics on existing toolchain/platform combinations subject > > > to community discussion on how/if/when. > > > > > > it would be good to get more participants into the discussion so > > > i'll cc techboard for some attention. i feel like the only area that > > > isn't decided is to do or not do this in rte_ namespace. > > > > > > i'm strongly in favor of rte_ namespace after discussion, mainly due > > > to to disadvantages of trying to overlap with the standard namespace > > > while not providing a compatible api/abi and because it provides > > > clear disambiguation of that difference in semantics and compatibilit= y with > the standard api. > > > > > > so far i've noted the following > > > > > > * we will not provide the non-explicit apis. > > +1 > > > > > * we will make no attempt to support operate on struct/union atomics > > > with our apis. > > +1 > > > > > * we will mirror the standard api potentially in the rte_ namespace t= o > > > - reference the standard api documentation. > > > - assume compatible semantics (sans exceptions from first 2 points)= . > > > > > > my vote is to remove 'potentially' from the last point above for > > > reasons previously discussed in postings to the mail thread. > > > > > > thanks all for the discussion, i'll send up a patch removing > > > non-explicit apis for viewing. > > > > > > ty