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 1190441C82; Mon, 13 Feb 2023 06:05:05 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 97EC840DDB; Mon, 13 Feb 2023 06:05:04 +0100 (CET) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04on2047.outbound.protection.outlook.com [40.107.6.47]) by mails.dpdk.org (Postfix) with ESMTP id DB4AC40A81; Mon, 13 Feb 2023 06:05:03 +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=OeNYUK8q2wB3HBcBFVBrXNNMj5/AUEdixaedajBLPe0=; b=ah85lxpZtvNDcfGelXCEKCQDXwdOPVy6oP8ONBYT+dAb2KeHNpKN9l1cQdZQYkj1fif6HCq6NkEcukVihaoA32+oJ2UHj7vAyma21M3TEsLl3PyEGB6oMmz2wcSFmL9RGbg8elLFYZhuI9HwZRWPK5hPIzUXCtAOa9FeoqHCF/U= Received: from DB6PR0802CA0029.eurprd08.prod.outlook.com (2603:10a6:4:a3::15) by DB9PR08MB7745.eurprd08.prod.outlook.com (2603:10a6:10:394::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6086.23; Mon, 13 Feb 2023 05:05:01 +0000 Received: from DBAEUR03FT033.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:a3:cafe::c0) by DB6PR0802CA0029.outlook.office365.com (2603:10a6:4:a3::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6086.22 via Frontend Transport; Mon, 13 Feb 2023 05:05:01 +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 DBAEUR03FT033.mail.protection.outlook.com (100.127.142.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6086.21 via Frontend Transport; Mon, 13 Feb 2023 05:05:00 +0000 Received: ("Tessian outbound b1d3ffe56e73:v132"); Mon, 13 Feb 2023 05:05:00 +0000 X-CR-MTA-TID: 64aa7808 Received: from 336b87229760.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 19E2BF7C-E870-45D6-983F-96E3896CE926.1; Mon, 13 Feb 2023 05:04:54 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 336b87229760.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 13 Feb 2023 05:04:54 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GimCxfjoE7JlA22AP9p3HoMKyMONMKn1bkhEr85R0SpApxwG2XIFQC2B9Rz29pe+CwKZT/kMKL9axNAvzmPpceUu/vbpAZ5oF8mWhS7PFnMZXY8Pwq1UYTDR87XvKdf/PDStQT9HZtIcUM/qQgnDOn+d5rd0OV4XxSuwcEoVEsArjbdfSMnmx9rfcyR1D9l8I3uWkzmjFIUGH322tEV3ZLfphDNX995G/93/NpYFjly4QpSBv8mRbWyuzoEGNJPayMYWhsYMm5igsGtUWwGJepor12ACSKvVGl7PAETVBLHbRTeVNDmrHwGvuUekwvbuuWDxf7uTtkZyoGadfsAygA== 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=OeNYUK8q2wB3HBcBFVBrXNNMj5/AUEdixaedajBLPe0=; b=M7IoaCTJIpTL95krMMY3Qo6X3+BCDVDYfb5vYKvIP4ccTRugHoAY+kRXHz435TYWV23smwB0ru4jB+XapAsydr5rCdoT77s97P125BTs1+xzWNhaC+or13eCY/oMdGrg8xsoToX4GAS4TxMX1KMpi4PvOHnppCcXWhwVQEI+62CO8d7f5CqYCvTkRqzZP/HEYGvP6GRCLWqyhLWDiwhgneIdUtGTpzCtFaAx1sEbgH9i352aFtK+YgqeFZH2qBonXIHNU/OJu+Dy10uoxaSos5p5lWyIC2RfY1GInoQc3PL/Po2Rakng8T2NOmpPEP8cY4HqH3oVHwpLmG92UtRtnw== 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=OeNYUK8q2wB3HBcBFVBrXNNMj5/AUEdixaedajBLPe0=; b=ah85lxpZtvNDcfGelXCEKCQDXwdOPVy6oP8ONBYT+dAb2KeHNpKN9l1cQdZQYkj1fif6HCq6NkEcukVihaoA32+oJ2UHj7vAyma21M3TEsLl3PyEGB6oMmz2wcSFmL9RGbg8elLFYZhuI9HwZRWPK5hPIzUXCtAOa9FeoqHCF/U= Received: from DBAPR08MB5814.eurprd08.prod.outlook.com (2603:10a6:10:1b1::6) by AS8PR08MB6392.eurprd08.prod.outlook.com (2603:10a6:20b:31a::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6086.24; Mon, 13 Feb 2023 05:04:51 +0000 Received: from DBAPR08MB5814.eurprd08.prod.outlook.com ([fe80::f8c8:b4b6:c041:ac9d]) by DBAPR08MB5814.eurprd08.prod.outlook.com ([fe80::f8c8:b4b6:c041:ac9d%5]) with mapi id 15.20.6086.024; Mon, 13 Feb 2023 05:04:51 +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++r5EuVscptDtirzq65Kg2ggAF2NYCAAAyiAIAJnq4AgAB4YgCAAIctgIAAZAUAgAE9qYCAAMOQMIABAQqAgAOsgNA= Date: Mon, 13 Feb 2023 05:04:49 +0000 Message-ID: References: <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> <20230210203013.GB25500@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> In-Reply-To: <20230210203013.GB25500@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: 9B66C4F6ADFA1E4393868F439F4D28E1.0 x-checkrecipientchecked: true Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; x-ms-traffictypediagnostic: DBAPR08MB5814:EE_|AS8PR08MB6392:EE_|DBAEUR03FT033:EE_|DB9PR08MB7745:EE_ X-MS-Office365-Filtering-Correlation-Id: a9262853-212b-44e9-d492-08db0d7fdc21 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: ozSEJlLOizieVt13JgQcNrH32bOinFXNlBp1Na1aVdA6jaGjB508cD1BqFrSDmWgtM2bfwa3vVzbeo+B+OF/Nh4K8eUrUFhZCm7/ZXHOTDuvJYrdInk03sQzRxrqGmKC8/CfhLdZE3T5oAthlXkUjQkE1KyETZlexgnIDOukZ56hh4U0HozQtozT3Cv0fWcfYzQA+oJdpiz7KpQSoKD9rcSZhbNwGMmoUnTQtkAiCH8Ff2QVx1bPKJZwzIZLEuLV6+5LObTHVxjPW8VGpxYrKzuD6JcwVp5RQ6avIa/dZDtBu7O0eCFa45j2NyOMrBhT4QT7zBZBf2/TMifd2EEtd/mM3Qnu17enbTdHGIHxL8m0Tu1fS0JBUIeLvHaz4USVA6ucK2mpLn59exR9PTLTLraMaRoqLUgaQ5dK24P+EbSBHh0DXIynjd4RaztCySLv0ZwJmN7dCzT9famtuuX/AilmsiJ7FbCyXPtqabvi3GnlWzf0Apcebmayqn67pqK00I8tWOgxBrhF1wOUwRm7hcWjMmhY2x6ZyR5W1+aCobKt8pd2dRKaN6UGnDID9+aXLwMDe5gKpEDFgB3efUW3OENFKRM6PPX8CjxP8AV04lAS9yDyOZtChCLiEHLHP7IVEyLUMIo1GYSU4dKULN88VYIhOJtFR9bqTmObeDyC3rvaXiEJwo7uuvQg9aw5foHQtDOivIY+ejFQqbCzEhqqf0A27of5yDEwzWfBiqXcP4FXQAWVyQ5bQlHZ//gguguEyQpiN72mRP2EzYGoDqKDIx0991YeS5vmK9rsfSskpXg= 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)(39860400002)(346002)(396003)(366004)(376002)(136003)(451199018)(66899018)(41300700001)(54906003)(316002)(4326008)(52536014)(64756008)(66476007)(66946007)(8676002)(76116006)(6916009)(66556008)(66446008)(38070700005)(38100700002)(33656002)(55016003)(86362001)(122000001)(7696005)(53546011)(71200400001)(186003)(26005)(6506007)(9686003)(2906002)(5660300002)(30864003)(8936002)(7416002)(478600001)(966005)(66574015)(83380400001)(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: AS8PR08MB6392 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: DBAEUR03FT033.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 8786b595-ae4b-496c-3c86-08db0d7fd534 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: yKRLiZscYH5tCwm3BoC2kMlHoTa1STYUwiQsyub4PHL5ge/gcCkR8s5g6AiFWjz0TLI2g+t6ZWhvafyN+rSoLyh0WzvPEBwGbxRwWJ/06YFz+vHWnTgzh1DSeAuWaCJaud6mTnFl5D2mPovvXh+ZMGpBOecOrq3BMpIbVp8rz10aGqB15ttrgQCLlZ/USd70FCX+JQSgXJcAyV9+Lg7CirWFaZ9WBsqz0kAW6sk5cyGozsruXotSu48rijlck7/rC3zBTbrdQFe9QErVKR6s1Pur4Q0P6koNDPaSut03qj4ZjXWNvXGtc4e/SrFkvUpt1ZXwa/koxdQZuBbLxG1ZlTImuTmseOSC1H4Evyh42a22eWSlwUmyxKo6zAUpYFNk1w3Zoe1f/+LTuoZyc+L+CdJqbxxGU8eYiiBkyxdREvEFsT4Ho9etzfK1N/93yqqRzVPg5AcDB4iEdru7t3igLODp1ApjzGnPcYT6uPnDVZ/ZTvPdLcPBRFzoc8tQ6t+UyIcOIzTRRqH1KW17IuR2XL61UKCxnjZ51jKmxLKT1FVbYeiK/iC0fSW5GXS2fBxIiJRCUJjT3MZVGM9swoE/mYc/D4Tcxf/FwEcp1vw87SPXPFe9XBxVq9Mki9XL31oMug1QEiG6GJRfQ4Th/JpJNUDjIcWLLj/na0pE+9I0BJ4LqRxyCyCGpP7h25QE5QVuDdHZeqnyalAkBj/ilpf9AnsRvxAX7dWTH7ekrrl450xtFwqX34LYb37HB261pSoiV5cWjKPjhVq5SBmJS2UBx+wRhLhJrFsLNITZmZ63Otg= 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)(39860400002)(346002)(376002)(396003)(136003)(451199018)(46966006)(40470700004)(36840700001)(186003)(26005)(9686003)(316002)(7696005)(66899018)(53546011)(54906003)(6506007)(450100002)(966005)(478600001)(70206006)(70586007)(8676002)(4326008)(336012)(6862004)(8936002)(66574015)(47076005)(52536014)(41300700001)(30864003)(83380400001)(5660300002)(55016003)(356005)(2906002)(40460700003)(82740400003)(36860700001)(81166007)(86362001)(40480700001)(82310400005)(33656002)(21314003); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Feb 2023 05:05:00.8113 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a9262853-212b-44e9-d492-08db0d7fdc21 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: DBAEUR03FT033.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR08MB7745 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 Hi Tyler, Few more comments inline. Let us continue to make progress, I will add thi= s topic for Techboard discussion for 22nd Feb. > -----Original Message----- > From: Tyler Retzlaff > Sent: Friday, February 10, 2023 2:30 PM > To: Honnappa Nagarahalli > Cc: 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 > Subject: Re: [PATCH] eal: introduce atomics abstraction >=20 > On Fri, Feb 10, 2023 at 05:30:00AM +0000, Honnappa Nagarahalli wrote: > > > > > > > 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/Reser > > > > > > > > > ved- > > > > > > > > > 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 > introduced? > > > > > > > i.e. it should not apply if the compiler does not support std= atomics. > > > > > > > > > > > > > > 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 stdatom= ics. > > > > > > > > > > > > > > > > > > > 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 variable. > > > > > > > > > > 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 were > > > 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 us= e 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/stdatom > > > > ic.h > > > > [2] > > > > https://github.com/llvm-mirror/clang/blob/master/lib/Headers/stdat > > > > omic > > > > .h > > > > > > 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 by all implementations of c as an abstract langu= age). > > > > > > ISO/IEC 9899:2011 > > > > > > 6.2.5 (27) > > > Further, there is the _Atomic qualifier. The presence of the _Ato= mic > > > qualifier designates an atomic type. The size, representation, an= d > alignment > > > of an atomic type need not be the same as those of the correspond= ing > > > unqualified type. > > > > > > 7.17.6 (3) > > > NOTE The representation of atomic integer types need not have the > same size > > > as their corresponding regular types. They should have the same > > > size whenever > > > possible, as it eases effort required to port existing code. > > > > > > 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 current and potential future compilers atomic vs non-atomic > > > types. this as i'm sure you understand is not practical, it would > > > also defeat the purpose of moving to a standard. therefore i rely on > > > the specification prescribed by the standard not the detail of a spec= ific > implementation. > > Can we say that the platforms 'supported' by DPDK today do not have thi= s > problem? Any future platforms that will come to DPDK have to evaluate thi= s. >=20 > sadly i don't think we can. i believe in an earlier post i linked a bug f= iled on > gcc that shows that clang / gcc were producing different layout than the > equivalent non-atomic type. I looked at that bug again, it is to do with structure. >=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 > abstraction? > > > This covers the GCC and Clang compilers. >=20 > i haven't investigated fully but there are usages of these intrinsics tha= t > indicate there may be undesirable difference between clang and gcc versio= ns. > the hint is there seems to be conditionally compiled code under __clang__ > when using some __atomic's. I sent an RFC to address this [1]. I think the size specific intrinsics are= not necessary. [1] http://patches.dpdk.org/project/dpdk/patch/20230211015622.408487-1-honn= appa.nagarahalli@arm.com/ >=20 > for the purpose of this discussion clang just tries to look like gcc so i= don't > regard them as being different compilers for the purpose of this discussi= on. >=20 > > > > > > the namespace starting with `__` is also reserved for the implementat= ion. > > > this is why compilers gcc/clang/msvc place name their intrinsic and > > > builtin functions starting with __ to explicitly avoid collision > > > with the application namespace. >=20 > > Agreed. But, here we are considering '__atomic_' specifically (i.e. > > not just '__') >=20 > i don't understand the confusion __atomic is within the __ namespace that= is > reserved. What I mean is, we are not formulating a policy/rule to allow for any name = space that starts with '__'. >=20 > let me ask this another way, what benefit do you see to trying to overlap= with > the standard namespace? the only benefit i can see is that at some point = in > the future it avoids having to perform a mechanical change to eventually > retire the abstraction once all platform/toolchains support standard atom= ics. > i.e. basically s/rte_atomic/atomic/g >=20 > is there another benefit i'm missing? The abstraction you have proposed solves the problem for the long term. The= proposed abstraction stops us from thinking about moving to stdatomics. IMO, the problem is short term. Using the __atomic_ name space does not hav= e any practical issues with the platforms DPDK supports (unless msvc has a = problem with this, more questions below). >=20 > > > > > > > > ISO/IEC 9899:2011 > > > > > > 7.1.3 (1) > > > All identifiers that begin with an underscore and either an upper= case > > > letter or another underscore are always reserved for any use. > > > > > > ... > > > > > > > If there is another platform that uses the same name space for > > > > something > > > else, I think DPDK should not be supporting that platform. > > > > > > 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 mean to say a compiler for windows platform uses '__atomic_xxx' name > space to provide some other functionality (and hence it would get exclude= d)? >=20 > i mean dpdk can never fully be supported without msvc except for statical= ly > linked builds which are niche and limit it too severely for many consumer= s to > practically use dpdk. there are also many application developers who woul= d > like to integrate dpdk but can't and telling them their only choice is to= re-port > their entire application to clang isn't feasible. >=20 > i can see no technical reason why we should be excluding a major compiler= in > broad use if it is capable of building dpdk. msvc arguably has some of th= e > most sophisticated security features in the industry and the use of those > features is mandated by many of the customers who might deploy dpdk > applications on windows. I did not mean DPDK should not support msvc (may be my sentence below was m= isunderstood). Does msvc provide '__atomic_xxx' intrinsics? >=20 > > Clang supports these intrinsics. I am not sure about the merit of suppo= rting > other non-gcc compilers. May be a topic Techboard discussion. > > > > > > > > > What problems do you see? > > > > > > i'm fairly certain at least one other compiler uses the __atomic > > > namespace 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 comes to mind is if such an intrinsic with the same name is > > > provided in a different implementation and has either regressive > > > code generation or different semantics it would be bad because it is > > > intrinsic you can't just hack around 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 go= od > to find out more about a compiler that does this. >=20 > again, this is about portability it's about potential not that we can fin= d an > example. >=20 > > > > > > > > how about this, is there another possible namespace you might > > > suggest that conforms or doesn't conflict with the the rules defined > > > in ISO/IEC 9899:2011 > > > 7.1.3 i think if there were that would satisfy all of my concerns > > > related to namespaces. > > > > > > 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 implementation 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 > keep the problem scope narrow which might help us push to adopt the > standard sooner. >=20 > i do wish we could just target the standard but unless we are willing to = draw a > line and say no more non std=3Dc11 and also we potentially break the abi = we > are talking years. i don't think it is reasonable to block progress for y= ears, so > i'm offering a transitional path. it's an evolution over time that we hav= e to > manage. Apologies if I am sounding like I am blocking progress. Rest assured, we wi= ll find a way. It is just about which solution we are going to pick. Also, is there are any information on how long before we move to C11? >=20 > > > > > > > > i feel like we are really close on this discussion, if we can just > > > iron this issue out we can probably get going on the actual changes. > > > > > > thanks for the consideration. > > > > > > > > > > > > > > > > > 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 compatibility 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 atom= ics > > > > > with our apis. > > > > +1 > > > > > > > > > * we will mirror the standard api potentially in the rte_ namespa= ce to > > > > > - reference the standard api documentation. > > > > > - assume compatible semantics (sans exceptions from first 2 poi= nts). > > > > > > > > > > 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