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 7836A41C44; Thu, 9 Feb 2023 01:17:02 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 080E840DDA; Thu, 9 Feb 2023 01:17:02 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on2041.outbound.protection.outlook.com [40.107.15.41]) by mails.dpdk.org (Postfix) with ESMTP id 03A724067B; Thu, 9 Feb 2023 01:16:59 +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=ccejuBWvaV7D1zsuFJIBcz4f+8r7FGq6qUlVHkRWMFc=; b=bL+b/D45SzyLbu+r6J2D1OzCze01HgAFML3Ci00felZ6lqIplPBF8sQVSVkldTltLVJhTA0tj00mjoqCy928inI0UW34eIQT/IoE742p7n8nFdAnHQimdJ2ET6LRN8SIHfi4itYUOhsoa21XOQmbMakopYCXn9LVdgK3ubAAzkk= Received: from DUZPR01CA0114.eurprd01.prod.exchangelabs.com (2603:10a6:10:4bb::13) by VE1PR08MB5870.eurprd08.prod.outlook.com (2603:10a6:800:1a8::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6086.17; Thu, 9 Feb 2023 00:16:50 +0000 Received: from DBAEUR03FT047.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:4bb:cafe::c7) by DUZPR01CA0114.outlook.office365.com (2603:10a6:10:4bb::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6086.19 via Frontend Transport; Thu, 9 Feb 2023 00:16:50 +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 DBAEUR03FT047.mail.protection.outlook.com (100.127.143.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6086.18 via Frontend Transport; Thu, 9 Feb 2023 00:16:50 +0000 Received: ("Tessian outbound 0d7b2ab0f13d:v132"); Thu, 09 Feb 2023 00:16:50 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 69b0c1dc29450f29 X-CR-MTA-TID: 64aa7808 Received: from bed5fa0af661.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id F16D292C-7435-43EF-8331-509D8DB9723A.1; Thu, 09 Feb 2023 00:16:43 +0000 Received: from EUR02-AM0-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id bed5fa0af661.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 09 Feb 2023 00:16:43 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kHG8j8ej5cEj4U2lW09/sRAUK0kjOjjojH+5eAB/TP9kLXfiipgygN+Ghle9vatYiUy2O9xI1Qey5UqI//qzD1VjeuE4GbX5iQLAz5fpx6hYwBMUd8wqCXLEnn7M4qcc9sURUanf7gp/mLPftCw852SWGfS9QiuPTBFLYOzneW96dmrAmrd515e/E0unPUdUt6SAFEMAlWztsiYVxnB77lKHIgcb3TWXsIdYsya3l50C2LafOksNh5ouBsimzG1wCaGelQz7axHeyJGdZOUFELVXIlrHM8SpZPBQ9ikX17FlKeMXhdXXp30+8F0cryNnl1NYvf6sDaLUDDRJm96ysA== 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=ccejuBWvaV7D1zsuFJIBcz4f+8r7FGq6qUlVHkRWMFc=; b=W5z0KKvrZXh42cecuRMHbu9fuSkkIcDSmGgdPcNr03A2HvT6hQxdsg9QAj7k5XflKFFejGrr3PbgFMUjK5JvChirAoCF1M0XjtQDm3EPmDEzmt2jZGk5Uj6t33zz5F6ShBHu393f62uZauBckXreSQ/+stec38h1Skdm3hWvOCJPngJPpRyBfuufsCAaJ9mgP9uR6Npg+ifpANCx4yn0AGv55EdAhN8cVTyPmeZWdxtDK/zV1YgDbGh8CsZ7RDrOpdUsjuiN14U1Vbfm9TX0yiwNy6RgjgvlP6yy9xnh63S/P0SpWQ/4cL8I4Pkm5JQtaV42BxdTdxUM6B0Bd2qcoQ== 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=ccejuBWvaV7D1zsuFJIBcz4f+8r7FGq6qUlVHkRWMFc=; b=bL+b/D45SzyLbu+r6J2D1OzCze01HgAFML3Ci00felZ6lqIplPBF8sQVSVkldTltLVJhTA0tj00mjoqCy928inI0UW34eIQT/IoE742p7n8nFdAnHQimdJ2ET6LRN8SIHfi4itYUOhsoa21XOQmbMakopYCXn9LVdgK3ubAAzkk= Received: from DBAPR08MB5814.eurprd08.prod.outlook.com (2603:10a6:10:1b1::6) by AS8PR08MB8299.eurprd08.prod.outlook.com (2603:10a6:20b:56f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6086.17; Thu, 9 Feb 2023 00:16:40 +0000 Received: from DBAPR08MB5814.eurprd08.prod.outlook.com ([fe80::f8c8:b4b6:c041:ac9d]) by DBAPR08MB5814.eurprd08.prod.outlook.com ([fe80::f8c8:b4b6:c041:ac9d%6]) with mapi id 15.20.6086.017; Thu, 9 Feb 2023 00:16:39 +0000 From: Honnappa Nagarahalli To: Tyler Retzlaff , =?iso-8859-1?Q?Morten_Br=F8rup?= CC: "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++r5EuVscptDtirzq65Kg2ggAF2NYCAAAyiAIAJnq4AgAB4YgCAAIctgIAAZAUA Date: Thu, 9 Feb 2023 00:16:38 +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> In-Reply-To: <20230208163521.GB5117@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: A7E85B2F639D194381D7BD0CD14FA77D.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_|AS8PR08MB8299:EE_|DBAEUR03FT047:EE_|VE1PR08MB5870:EE_ X-MS-Office365-Filtering-Correlation-Id: 61ed30c2-efa4-4081-3b50-08db0a32f096 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: 8dU+VqCGt3fOysgfmPgrQXvm0ydGlfaQbK4CTM4yXp9nLjb/OKaGV/GAy+Xqe9fd1fhDhD0298A5T9Z/yzndSTHj/t7q+w9nH2z3/KyUqTPINaQTl3vtqNjhSF5h+lY93zaF+f3Vd1x0vpzNDslGsyrjmKD4sHKHjCLxQ1M2I9YxL9NdKrn+3fRWVaDBISmBMZYD40tbmX5Ipy/nUz4XenFjnNKzUGSzwLG1p0Wp06uOMxzXFXyA++Kjdz6ojD2hell8dmN3Bh3KFrwU+tGXSY8PNFW/ntVwqpi9nQXqS8ONcGMZ98gzrzg6WQCQHgYezv+BRQeSBeEXXtBhNcDcy1CcGANefoPt7Gl354NcRIgghg6Axb4oItqDzvHtcm/+fojg+Sy0awCOlo5WwWUzway9tfw6D7lz8sva1f/JsFHzS06FpYwkHDMAtkh/HIWcijg02PBBO4RxUVaZZztsKwZPyXY7IfjjriUwImZ2IsMSVCqEMhOoUzCbOc13ElY0vcxYTGGaEP6E5EDU6LxbwHkLygh34I4Zq8RO9JPam6wm7bHw6EJ7IVfZgadHPO14x6wJZ0aX+oubHFsPHJoXbzeyqdBL/MkNWJepKa0pwJEoYAxf4KHYkoXFWg2nednxoNKU27sWegxpHDCP/Zk5xMPMbwAtCAHvoFZc18e0lFg78AiGMAhjbVA8ZOKcedjmEzz9rZ4nBQqeVlSiUihJyJqSnMxu2dQZwiGoZOYtsjn9HEZYOvegckyOYPi6pBLWfGJPbiS/MdknyY0FBqPBPew0hjczwkZcBme5txcwJmU= 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)(376002)(366004)(396003)(346002)(136003)(451199018)(66946007)(66476007)(64756008)(66446008)(33656002)(4326008)(76116006)(66556008)(8676002)(41300700001)(52536014)(6506007)(8936002)(26005)(186003)(71200400001)(7696005)(478600001)(966005)(316002)(86362001)(54906003)(110136005)(83380400001)(2906002)(9686003)(7416002)(55016003)(5660300002)(38070700005)(122000001)(38100700002)(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: AS8PR08MB8299 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: DBAEUR03FT047.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: bbb3767a-746e-4026-41e3-08db0a32e9c9 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: r0rni4f1cuNMgM9pAOQHOOqUsGiMc3R7r/fYRJIqI5kpsHNE91zj1rlu6/opUQZbVEuKxc+gvh38NWGH9fJ2thzfQMdWv2TOgCj44AmdSrYHh8p8drjAUuaHaksLey9qHOuutGBkNuj5Md60maASphE3jZMHNV1oE8x/R/jwswE8kQftTCErnq8R+GX7JfBhiCAau61PvI6vlX2Wnh9Ln3b23UvOXYRu6KoAdlKAqTnJFrM+ygqBKQSLO1p0kuV3ww8lQ2jA/QkaK1aJk/BZHNTKwyoQoXfZUT/UpAOHRCLfbVwlvlTvoXqpTqhmjbPRptmHujgWoPaoWJsXaLSS23IdIEccgsEZvNYvOAnnO6+FBFhTvws7rYS2vwT3XOvqmEJ8HdV9M/oriRONeD7SxvQGmqshDorhNYoJq5zKjutUZDCNGUAikxvbT6UOqTs9Cn6B/ESLYyZfdCsKXo/9bkzuFwfUfvTSHBwLY5N2c6/hZ+HfFnytHFgL3I+0E6FlpVg7PAmIL8Ac70uj5AKSe9lchi9mAerhrUX9GdGfSF5vp1ZTz2f+P+p1a0vTAA1NQ69MYpX+/INKYZ908hU2e7vLb9dpl/eo1xW3b5ymf/djkxcI82K0mT3BKvnU2NF8yPwZpTVpXJxzz4+zm+yz3bL5mppCZYWTwXRKXiFbwef1qy6aiLaOkHz6jXQtGcCHI1SeEd0omEgknBoYGRFYnRBBOS4WnrmQz+x7ilbLKiUeWplZuDVWvY32rBfBywQNzG0dgHIMT3RmofwjiNAXreHV+YPQ8XF8kiz8H7jRddg= 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)(396003)(376002)(39860400002)(136003)(346002)(451199018)(46966006)(36840700001)(40470700004)(5660300002)(47076005)(2906002)(81166007)(83380400001)(40480700001)(336012)(356005)(55016003)(70586007)(82740400003)(36860700001)(8676002)(70206006)(4326008)(54906003)(450100002)(110136005)(8936002)(26005)(52536014)(41300700001)(40460700003)(186003)(33656002)(9686003)(6506007)(7696005)(316002)(478600001)(86362001)(966005)(82310400005)(21314003); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Feb 2023 00:16:50.3920 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 61ed30c2-efa4-4081-3b50-08db0a32f096 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: DBAEUR03FT047.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB5870 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 > > > > > > > > > > > > > > > > > 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 introduced? > > > i.e. it should not apply if the compiler does not support stdatomics. > > > > > > 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 wi= th a > separate application build environment, they both have to implement atomi= cs > 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 compi= led > code; i.e. it must be possible for both compiled DPDK functions and inlin= e > functions to perform atomic transactions on the same atomic variable. >=20 > i consider it a mandatory requirement. i don't see practically how we cou= ld > withdraw existing use and even if we had clean way i don't see why we wou= ld > want to. so this item is defintely settled if you were concerned. I think I agree here. >=20 > > > > So either we upgrade the DPDK build requirements to support C11 (includ= ing > the optional stdatomics), or we provide our own DPDK atomics. >=20 > i think the issue of requiring a toolchain conformant to a specific stand= ard is a > separate matter because any adoption of C11 standard atomics is a potenti= al > 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 > the abstraction (whatever namespace it resides) allows the existing > toolchain/platform combinations to maintain compatibility by defaulting t= o > current non-standard intrinsics. How about using the intrinsics (__atomic_xxx) name space for abstraction? T= his covers the GCC and Clang compilers. If there is another platform that uses the same name space for something el= se, I think DPDK should not be supporting that platform. What problems do you see? >=20 > once in place it provides an opportunity to introduce new toolchain/platf= orm > combinations and enables an opt-in capability to use stdatomics on existi= ng > toolchain/platform combinations subject to community discussion on > how/if/when. >=20 > 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. >=20 > i'm strongly in favor of rte_ namespace after discussion, mainly due to t= o > disadvantages of trying to overlap with the standard namespace while not > providing a compatible api/abi and because it provides clear disambiguati= on of > that difference in semantics and compatibility with the standard api. >=20 > so far i've noted the following >=20 > * 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 to > - reference the standard api documentation. > - assume compatible semantics (sans exceptions from first 2 points). >=20 > my vote is to remove 'potentially' from the last point above for reasons > previously discussed in postings to the mail thread. >=20 > thanks all for the discussion, i'll send up a patch removing non-explicit= apis for > viewing. >=20 > ty