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 3A9BF42395; Tue, 10 Jan 2023 21:10:36 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D800C40E25; Tue, 10 Jan 2023 21:10:35 +0100 (CET) Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mails.dpdk.org (Postfix) with ESMTP id 1BB5A4021E for ; Tue, 10 Jan 2023 21:10:34 +0100 (CET) Received: by linux.microsoft.com (Postfix, from userid 1086) id 4845820B3718; Tue, 10 Jan 2023 12:10:33 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 4845820B3718 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1673381433; bh=blZsq3Qbj/HimbnLvjZjOPAQy0M+3IocjOBNIHsSMnI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=L2oY8FrDuxZS+x+U3f++9zl7+ncXLxPqTHzV6zV73W9tR4+IlelnbQGSV0hKTGKbz P2TlK/MnfjcTXL94R+lTPvx7zKnuFMdxZQCFdVt6lB8Gku/eYtNPAzIPaedN/8PMa4 pfIgl2XmFh2GlQWdV0iccXClo40BX2VQqntBAEeo= Date: Tue, 10 Jan 2023 12:10:33 -0800 From: Tyler Retzlaff To: Bruce Richardson Cc: dev@dpdk.org Subject: Re: RFC abstracting atomics Message-ID: <20230110201033.GC21476@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> References: <20230109225604.GA25566@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, Jan 10, 2023 at 09:16:48AM +0000, Bruce Richardson wrote: > On Mon, Jan 09, 2023 at 02:56:04PM -0800, Tyler Retzlaff wrote: > > hi folks, > > > > i would like to introduce a layer of abstraction that would allow > > optional use of standard C11 atomics when the platform / toolchain > > combination has them available. > > > > making the option usable would be a phased approach intended to focus > > review and minimize dealing with churn on such a broad change. > > > > 1. provide an initial series to add the abstraction and the ability > > control enablement with a meson option enable_stdatomics=false will > > be the default. > > > > for all existing platform / toolchain combinations the default would > > remain false. i.e. i have no plans to enable it for existing platforms > > toolchain combinations but leaves a change of default open to the > > community as a future discussion if it is desired. > > > > 2. once the initial abstraction is integrated a series will be introduced to > > port the tree to the abstraction with enable_stdatomics=false. the goal > > being low or no change to the current use of gcc builtin C++11 memory > > model atomics. > > > > 3. once the tree is ported a final series will be introduced to introduce > > the remaining change to allow the use of enable_stdatomics=true. > > > > would appreciate any assistance / suggestions you can provide to > > introduce the abstraction smoothly. > > > > Plan generally sounds ok. However, beyond point #3, would there then be > plans to remove the option and always use stdatomics in future? that is a discussion for the community i think on a per-platform / per-toolchain basis. there is likely to be resistance which is why i'm favoring the opt-in if you want model. some potential arguments against switching. * it's an abi break there is no way around it. * old compiler x stdatomics implementation is less optimal than old compiler x __atomics (potential argument). * there's some "mixed" use of variables in the tree where sometimes we operate on them as if they are atomic and sometimes not. the std atomics apis doesn't support this sometimes atomic codegen you either get atomic or you don't. * direct use of atomics default to seq_cst ordering if the strengthening of the ordering is not desired each variable needs to be hunted down and explicitly returned to relaxed ordering access. > To slightly expand the scope of the discussion - would it be worthwhile > putting these abstractions in a new library in DPDK other than EAL, to > start the process of splitting out some of the lower-level material from > that library? the abstraction as i have prototyped it is a set of conditionally compiled macros where the macros mirror the standard c atomics for naming and have been placed in include/generic/rte_atomics.h i've no problem splitting it out into a separate library and then have EAL depend on it, but it is currently header only so i'm not sure if it is worth doing for that. we can chew on that more in a couple days when i submit the base series if you like. > > /Bruce