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 1431341C35; Wed, 8 Feb 2023 02:20:43 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8926140E6E; Wed, 8 Feb 2023 02:20:42 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 7D37F40DDB for ; Wed, 8 Feb 2023 02:20:41 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1086) id B953920C7E3B; Tue, 7 Feb 2023 17:20:40 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com B953920C7E3B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1675819240; bh=MWE9t4GGZk+d5KQNQrJnUMVsf6d7uGfHARpsrZbx/VE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=IEvwvSpOVOOWF7P4KZAMI7x6CARvvBWrR5393tSOHfyUtBniZcYgYdITzBSP5NERS w3si0GYl6ba6ChRYXSjroE0qCla+YDgLfHV8sEVI9xb0nlBGNoWRHHWqCd0gE1rxTl 0V/+Q9f0rfxKjZlFMmTJvhk2UG3qRj30hLNfBO3Y= Date: Tue, 7 Feb 2023 17:20:40 -0800 From: Tyler Retzlaff To: Honnappa Nagarahalli Cc: "thomas@monjalon.net" , "dev@dpdk.org" , "bruce.richardson@intel.com" , "mb@smartsharesystems.com" , "david.marchand@redhat.com" , "jerinj@marvell.com" , "konstantin.ananyev@huawei.com" , "ferruh.yigit@amd.com" , nd Subject: Re: [PATCH] eal: introduce atomics abstraction Message-ID: <20230208012040.GA22219@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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 Tue, Feb 07, 2023 at 11:34:14PM +0000, Honnappa Nagarahalli wrote: > > > > > > > > > > Honnappa, please could you give your view on the future of atomics in > > DPDK? > > > Thanks Thomas, apologies it has taken me a while to get to this discussion. > > > > > > IMO, we do not need DPDK's own abstractions. APIs from stdatomic.h > > (stdatomics as is called here) already serve the purpose. These APIs are well > > understood and documented. > > > > i agree that whatever atomics APIs we advocate for should align with the > > standard C atomics for the reasons you state including implied semantics. > Another point I want to make is, we need 'xxx_explicit' APIs only, as we want memory ordering explicitly provided at each call site. (This can be discussed later). i don't have any issue with removing the non-explicit versions. they're just just convenience for seq_cst anyway. if people don't want them we don't have to have them. > > > > > > > > > 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. > > > > > let's discuss this from here. if there's still overwhelming desire to go this route > > then we'll just do our best. > > > > ty