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 C565643F05; Tue, 30 Apr 2024 18:52:53 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8D71E402A8; Tue, 30 Apr 2024 18:52:53 +0200 (CEST) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id C658F400EF; Tue, 30 Apr 2024 18:52:51 +0200 (CEST) Received: by linux.microsoft.com (Postfix, from userid 1086) id 1FC15210FBDD; Tue, 30 Apr 2024 09:52:51 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 1FC15210FBDD DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1714495971; bh=pXcBSIxdQ0WAv53qNN/uNALfobJF5puBm4YugDJ8rmg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mr9BKyXT0POy038Rx3fBB07GfdrHOKGaFFMlKG+smyFlYO+XewqYrvmJZzEcAYvKy o51SbP5nle9RdJuEPs5PwLvV6qmuGYpznLFqALiGmAKL0J2GWW9y4bHFSueamnMyZ/ qcqguyO/E7y8pEIv0sCpjoDdTasyBXnqAV6o7ZlM= Date: Tue, 30 Apr 2024 09:52:51 -0700 From: Tyler Retzlaff To: Mattias =?iso-8859-1?Q?R=F6nnblom?= Cc: Morten =?iso-8859-1?Q?Br=F8rup?= , Mattias =?iso-8859-1?Q?R=F6nnblom?= , dev@dpdk.org, Heng Wang , Stephen Hemminger , techboard@dpdk.org Subject: Re: [RFC v2 5/6] eal: add atomic bit operations Message-ID: <20240430165251.GA7283@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20240302135328.531940-2-mattias.ronnblom@ericsson.com> <20240425085853.97888-1-mattias.ronnblom@ericsson.com> <20240425085853.97888-6-mattias.ronnblom@ericsson.com> <98CBD80474FA8B44BF855DF32C47DC35E9F3E8@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35E9F3EF@smartserver.smartshare.dk> <7e469926-0c09-42a4-aa8f-8cde0578690b@lysator.liu.se> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7e469926-0c09-42a4-aa8f-8cde0578690b@lysator.liu.se> 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 Fri, Apr 26, 2024 at 11:39:17AM +0200, Mattias Rönnblom wrote: [ ... ] > > > >> > >>The only reason for _Atomic being as it is, as far as I can see, is to > >>accommodate for ISAs which does not have the appropriate atomic machine > >>instructions, and thus require a lock or some other data associated with > >>the actual user-data-carrying bits. Neither GCC nor DPDK supports any > >>such ISAs, to my knowledge. I suspect neither never will. So the cast > >>will continue to work. > > > >I tend to agree with you on this. > > > >We should officially decide that DPDK treats RTE_ATOMIC types as a union of _Atomic and non-atomic, i.e. operations on RTE_ATOMIC types can be both atomic and non-atomic. > > > > I think this is a subject which needs to be further explored. > > Objects that can be accessed both atomically and non-atomically > should be without _Atomic. With my current understanding of this > issue, that seems like the best option. i've been distracted by other work and while not in the scope of this series i want to say +1 to having this discussion. utilizing a union for this atomic vs non-atomic access that appears in practice is a good idea. > > You could turn it around as well, and have such marked _Atomic and > have explicit casts to their non-_Atomic cousins when operated upon > by non-atomic functions. Not sure how realistic that is, since > non-atomicity is the norm. All generic selection-based "functions" > must take this into account. the problem with casts is they are actually different types and may have different size and/or alignment relative to their non-atomic types. for current non-locking atomics the implementations happen to be the same (presumably because it was practical) but the union is definitely a cleaner approach. > > >> > >>>>+ unsigned int nr, int memory_order) \ > >>>>+ { \ > >>>>+ RTE_ASSERT(nr < size); \ > >>>>+ \ > >>>>+ const RTE_ATOMIC(uint ## size ## _t) *a_addr = \ > >>>>+ (const RTE_ATOMIC(uint ## size ## _t) *)addr; \ > >>>>+ uint ## size ## _t mask = (uint ## size ## _t)1 << nr; \ > >>>>+ return rte_atomic_load_explicit(a_addr, memory_order) & > >>mask; \ > >>>>+ } > >>> > >>> > >>>Similar considerations regarding volatile qualifier for the "once" > >>operations. > >>>