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 84CC0A0C40; Sun, 4 Jul 2021 02:37:51 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 298E540040; Sun, 4 Jul 2021 02:37:51 +0200 (CEST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mails.dpdk.org (Postfix) with ESMTP id E74F64003F for ; Sun, 4 Jul 2021 02:37:49 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 1A9805C00A9; Sat, 3 Jul 2021 20:37:49 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sat, 03 Jul 2021 20:37:49 -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= 4070l2O/92p+s/j0X9W2+DPn6fuRm+fxH/VujPfK3cA=; b=cyH7qnqmty/7jkLU myw6IbgKSEYnWF063RNL8J8TzRe3O8gRJlljSTiw+2rwF35euUNP0h67tD7Jb3tX 70VxzATVTF9hu41IBIw451TQJ7SpR5xDd6ufhhovqPD+iRpzVkO5wj6m8GcSAnjT Ml95UrzAVPpoLznzWmau78lCECPoYi/jUrF+sKGxGxzdgvFtrB8NZX5nt9+V0xjT 5eENMajUheoFwInm3QMMUkMbN5wwRgJ3edh+6la/6875+di5xisoIcGsdkWqxiGO L5us9ru3AWfi7ec3mSg7wt4utuxYQMyBR0P47/pOg3R5F47hncIQZp4Wfe4LeYM1 peRG4w== 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=4070l2O/92p+s/j0X9W2+DPn6fuRm+fxH/VujPfK3 cA=; b=m61dBN+qqjuh+ewUjhvHrQHurVKXzVtePQiC3M+pV/DDCMME6Fs0aGfuA qTYJ2IwIVh6Nv8jP+RdrfjZiTq8wyatyxWLXoJHjaRJ9wrYLiqweJhnc2bKmP4ze 9V6gJy4BXuHL6wkHpBQKRnbvt/vBq9Kyl6FPZK1HhyeD4xiL5SOahGdwgzL8VVwJ YhOLkOkFM7HoD9ixNF3sm7Aj0gsEvQsPjV0BW7+wN1IS7/lvDTqSHIHmFRzridoS W+ST3d733pfEtx2AYMaFREjVtS09cUwfJ5Gw3NZclYdAwYVmxSpJNkAz9jWTBTlt P96EzEoJDwDoMHBpDDtCSCj6VRJSg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeejuddgfeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepffdvffejueetleefieeludduuefgteejleevfeekjeefieegheet ffdvkeefgedunecuffhomhgrihhnpeguphgukhdrohhrghenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhn rdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 3 Jul 2021 20:37:46 -0400 (EDT) From: Thomas Monjalon To: honnappa.nagarahalli@arm.com, ruifeng.wang@arm.com, Phil Yang Cc: dev@dpdk.org, bruce.richardson@intel.com, konstantin.ananyev@intel.com, dev@dpdk.org, david.marchand@redhat.com, David Christensen Date: Sun, 04 Jul 2021 02:37:44 +0200 Message-ID: <1806192.QIeOlYoxj9@thomas> In-Reply-To: <1879045.6WiRxTbeAL@thomas> 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" 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? We are missing clear recommendations. > Should we keep these notifications forever? > > 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#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. Precision: I meant "there is *no* example". > Please who could work on improving the documentation? One simple example: increment a counter atomically. __atomic_fetch_add(&counter, 1, __ATOMIC_RELAXED); or __atomic_add_fetch(&counter, 1, __ATOMIC_RELAXED);