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 AAA71A0C49; Wed, 7 Jul 2021 21:28:58 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 72153413DB; Wed, 7 Jul 2021 21:28:58 +0200 (CEST) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by mails.dpdk.org (Postfix) with ESMTP id E7D65413B6 for ; Wed, 7 Jul 2021 21:28:56 +0200 (CEST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id 4181E58066C; Wed, 7 Jul 2021 15:28:56 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 07 Jul 2021 15:28:56 -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= DZINYqsP22RE5aulLStbJh/w7uzOxrY0mXTSdI24IU8=; b=K/QxkhLqueH7O8+C Gr2t0+IVuiZC4oneta8npP7W7HcFUF4mq4KnPWri0kI+odOaDmzCIIh7gFZ1vAny CRwFRYwTqWuijqv64rZcl6tsNMaQWEipEooL1zldQ8FhR5k17Zxp0kTunmSm+dpN 2N3hGu8EwEiahPbCbPOAVNMtIIc9HdCSI2JPixUyLOuL7PuUDrRT5PA4lHXWvCk2 XnAvx1Dlz2w1XftoOAfZmEvVx+TJ5QndSWu0/+t7JPFH243ehsJoU2h27tF8fL2t b8HPYGgMXulTZEltN1aWjF8gXbqiAC1bwtjQ0+Bn+4WKcXH1KgYu/aJCRgn2UDGm ZY9JHw== 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=DZINYqsP22RE5aulLStbJh/w7uzOxrY0mXTSdI24I U8=; b=f7rc98V7uzZOFT50OpemgCI8LADOpnTVKUwtBD+LqOLBuVCI0ovEiUs+F WOypWkgA+99AQ/7pV6etKGDvFsLfgykeYnusSiP+M2H2oy7yb1OIXARu0xhCw2Bg Cn7VnEDownPtRx/cB+Is5D1B0wfhUAk/UyRz36ql2D3t2ReO25LtpOmt7vkqcn4u PNyyVjfhCTeiu6dPIKN16/8SGdu87zPOPWb3QYvuw0xxt9fo+f9ZXYtrbTKND4rw vkzLAcKboxDrs9VnGKkzQ9B4rpppNwogYQoqggmYVpBnzwqo/PTS0HdjzPQ9psHg BcO9+ZwK0eMroB6v4W/MwvZA7otyQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrtddvgddufeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepffdvffejueetleefieeludduuefgteejleevfeekjeefieegheet ffdvkeefgedunecuffhomhgrihhnpeguphgukhdrohhrghenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhn rdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 7 Jul 2021 15:28:54 -0400 (EDT) From: Thomas Monjalon To: Ruifeng Wang , Phil Yang , Honnappa Nagarahalli Cc: "bruce.richardson@intel.com" , "konstantin.ananyev@intel.com" , "dev@dpdk.org" , "david.marchand@redhat.com" , David Christensen , nd , Honnappa Nagarahalli , nd Date: Wed, 07 Jul 2021 21:28:52 +0200 Message-ID: <2562130.VnibWpNGkk@thomas> In-Reply-To: References: <1879045.6WiRxTbeAL@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" 07/07/2021 21:04, Honnappa Nagarahalli: > > > > > > 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. > > " > > > > Should we keep these notifications forever? > I do not think we need to keep them forever (unless the precedence is to keep all the older deprecations). > > > > > It is very difficult to find which wrapper to use. > Actually, the deprecations are incorrect on the 'wrappers'. > When the deprecations were added, the understanding was we will develop wrappers, the discussion was not concluded. When we made the decision, we decided to use the C++11 atomic built-ins. Only wrapper developed was rte_atomic_thread_fence. This is documented in the following blog. > > > > > This is the guide we have: > > https://doc.dpdk.org/guides/prog_guide/writing_efficient_code.html#locks- > > 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. > > Please who could work on improving the documentation? > There is good amount of information on how to use the __atomic builtins for counters, memory barriers etc. > It would make sense to document something in DPDK if we implement our own wrappers. Please fix deprecation notice and think about how to document the compiler builtin choice.