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 BA446A0A0F; Mon, 5 Jul 2021 09:30:12 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 450E840141; Mon, 5 Jul 2021 09:30:12 +0200 (CEST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mails.dpdk.org (Postfix) with ESMTP id 999204003C for ; Mon, 5 Jul 2021 09:30:10 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id BD4745C00F5; Mon, 5 Jul 2021 03:30:07 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 05 Jul 2021 03:30:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm1; bh= KgwXDsLLioExfUgh8NIPFnowrVwsFl1OtBFNBCFuJSg=; b=Z9cfu1fKDp7Q9fzk De604FHIXE2fPTFe/X5wb810Vkp+AL5CAQpYAhdvfdGR13gIckiHiDGDZKfUF0vj zPj88B+/kIg+gqIKeJvSqjTAivIfoDGZpGbHwW0YvIWL9tXgvkvXLO64VR9aZOj4 GiQPPeOkWS8qm5R0nyOlal5CePzk7PIeAz/cLn/rg71R2ClJv05K6NGvB39EH+Xf //cFW1sJIDP7YYVlj5ByagJPFSw/uIxAqzIiiJlWXd0AOM4c1K7Q4lc09hLiH45d GDdS2acgMkDzGT0VMfZz+X4AHyow0KXPkaN71jipusv2yLVu2vumgdsj7ZfLsi9x bItrfw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=KgwXDsLLioExfUgh8NIPFnowrVwsFl1OtBFNBCFuJ Sg=; b=TPYFdH0M/P+fo3MFCmj7Jg6bIYveAoKXtVrPPwQCpbCes8myzZ5RIkvLP vWOm0yhiGl1UyFI/3HYiZ1bYqFsWsVnfi2NRbZ+PcYEjJG0o8qSkK5boAIj6y0br GQtZ/bOI7+M/adFdaohzyz4QplOEQuz5BcDARgkvCtcRxBX90rfeu/gATqfylXvR ew33FptTaRDevbPp/JGBgjE+m+Suo+ORuAjS7EaO660+qOEMVa27+jYhIJC5IfQ0 BtT/ruk7LvuLuYjnJQ7afyQSV/AF6Rp7nHJMBsEcdtCPG0MBlMnKCgr9uGQ0hR6u N0rqPFuFHQO+5ClGyepteo/gimoMA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeejfedguddtgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeffvdffjeeuteelfeeileduudeugfetjeelveefkeejfeeigeeh teffvdekfeegudenucffohhmrghinhepughpughkrdhorhhgnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 5 Jul 2021 03:30:05 -0400 (EDT) From: Thomas Monjalon To: Honnappa Nagarahalli , Ruifeng Wang Cc: "dev@dpdk.org" , "bruce.richardson@intel.com" , "konstantin.ananyev@intel.com" , "dev@dpdk.org" , "david.marchand@redhat.com" , David Christensen , nd Date: Mon, 05 Jul 2021 09:30:02 +0200 Message-ID: <2658239.2zj59f8sm8@thomas> In-Reply-To: References: <1879045.6WiRxTbeAL@thomas> <1806192.QIeOlYoxj9@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] atomic operations 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 Sender: "dev" 05/07/2021 09:00, Ruifeng Wang: > From: Thomas Monjalon > > 03/07/2021 13:29, Thomas Monjalon: > > > In the deprecation notices of DPDK 21.05, we can still read this: > > > " > > > * rte_atomicNN_xxx: These APIs do not take memory order parameter. > > This does > > > not allow for writing optimized code for all the CPU architectures > > supported > > > in DPDK. DPDK will adopt C11 atomic operations semantics and provide > > wrappers > > > using C11 atomic built-ins. These wrappers must be used for patches that > > > need to be merged in 20.08 onwards. This change will not introduce any > > > performance degradation. > > > > > > * rte_smp_*mb: These APIs provide full barrier functionality. However, > > many > > > use cases do not require full barriers. To support such use cases, DPDK will > > > adopt C11 barrier semantics and provide wrappers using C11 atomic built- > > ins. > > > These wrappers must be used for patches that need to be merged in > > 20.08 > > > onwards. This change will not introduce any performance degradation. > > > " > > > > The only new wrapper is rte_atomic_thread_fence(). What else? > > Yes. The decision was to use GCC atomic built-ins directly. > And rte_atomic_thread_fence() is an exception. It is a wrapper of __atomic_thread_fence(), because mem order __ATOMIC_SEQ_CST has an optimized implementation for x86. Then above deprecation is wrong. > > We are missing clear recommendations. > > > > > Should we keep these notifications forever? > > Targeting to obsolete APIs rte_atomicNN_xxx and rte_smp_*mb. > Arm is working on replace occurrences with equivalent atomic built-ins. > There is still a lot work to do in drivers. This is an ongoing work. In the meantime we need clear recommendation what to use. > > > It is very difficult to find which wrapper to use. > > > > We should make function names explicit instead of "These". > > > > > This is the guide we have: > > > https://doc.dpdk.org/guides/prog_guide/writing_efficient_code.html#loc > > > ks-and-atomic-operations > > > There are 2 blog posts: > > > https://www.dpdk.org/blog/2021/03/26/dpdk-adopts-the-c11-memory- > > model/ > > > https://www.dpdk.org/blog/2021/06/09/reader-writer-concurrency/ > > > > > > Basically it says we should use "__atomic builtins" but there is > > > example for simple situations like counters, memory barriers, etc. > > > > Precision: I meant "there is *no* example". > > > > > Please who could work on improving the documentation? > > Agree that the documentation needs improve. > Add link to list of atomic built-ins and the above mentioned blog posts can be part of the improvement. It should be more than a link. We need to know when to use what. First thing, please fix the deprecation notice. > > One simple example: increment a counter atomically. > > __atomic_fetch_add(&counter, 1, __ATOMIC_RELAXED); or > > __atomic_add_fetch(&counter, 1, __ATOMIC_RELAXED); I really hate how atomics are "documented" in GCC doc. For instance, it doesn't say what is returned (old or new value) in above functions.