From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ferruh Yigit Subject: Re: [PATCH v6] eal/x86: add 128-bit atomic compare exchange Date: Thu, 4 Apr 2019 12:47:00 +0100 Message-ID: References: <20190403193541.28044-1-thomas@monjalon.net> <20190403194456.13133-1-gage.eads@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: dev@dpdk.org, olivier.matz@6wind.com, arybchenko@solarflare.com, bruce.richardson@intel.com, konstantin.ananyev@intel.com, gavin.hu@arm.com, Honnappa.Nagarahalli@arm.com, nd@arm.com, chaozhu@linux.vnet.ibm.com, jerinj@marvell.com, hemant.agrawal@nxp.com, Thomas Monjalon To: Gage Eads , Shahaf Shuler , Matan Azrad , Yongseok Koh Return-path: Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id 908941B227 for ; Thu, 4 Apr 2019 13:47:06 +0200 (CEST) In-Reply-To: <20190403194456.13133-1-gage.eads@intel.com> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 4/3/2019 8:44 PM, Gage Eads wrote: > This operation can be used for non-blocking algorithms, such as a > non-blocking stack or ring. > > It is available only for x86_64. > > Signed-off-by: Gage Eads > Reviewed-by: Honnappa Nagarahalli > --- > This patch addresses x86-64 only; other architectures can/will be supported > in the future. The __atomic intrinsic was considered for the implementation, > however libatomic was found[1] to use locks to implement the 128-bit CAS on at > least one architecture and so is eschewed here. The interface is modeled after > the __atomic_compare_exchange_16 (which itself is based on the C++11 memory > model) to best support weak consistency architectures. > > This patch was originally part of a series that introduces a non-blocking stack > mempool handler[2], and is required by a non-blocking ring patchset. This > patch was spun off so that the the NB ring depends only on this patch > and not on the entire non-blocking stack patchset. > > [1] http://mails.dpdk.org/archives/dev/2019-January/124002.html > [2] http://mails.dpdk.org/archives/dev/2019-January/123653.html > > v6: > - Use @code and @endcode to clean up pseudo-code generation > - Add note that the function is currently limited to x86-64 > > v5: > - Move declaration in the generic file for doxygen only (Thomas) > > v4: > - Move function declaration from generic/rte_atomic.h to x86-64 header file > > v3: > - Rename function to ISA-neutral rte_atomic128_cmp_exchange() > - Fix two pseudocode bugs in function documentation > > v2: > - Rename function to rte_atomic128_cmpxchg() > - Replace "=A" output constraint with "=a" and "=d" to prevent GCC from using > the al register for the sete destination > - Extend 'weak' definition to allow non-atomic 'exp' updates. > - Add const keyword to 'src' and remove volatile keyword from 'dst' > - Put __int128 in a union in rte_int128_t and move the structure definition > inside the RTE_ARCH_x86_64 ifdef > - Drop enum rte_atomic_memmodel_t in favor of compiler-defined __ATOMIC_* > - Drop unnecessary comment relating to X86_64 > - Tweak the pseudocode to reflect the 'exp' update on failure. > <...> I am getting a build error, I guess generated from this patch, while building mlx drivers, when MLX._DEBUG enabled [1]. This looks because of the "-pedantic" parameter mlx drivers have [2]. Gage, Shahaf, Matan, Yongseok, Can you please check this? [1] .../dpdk/x86_64-native-linuxapp-gcc/include/rte_atomic_64.h:223:3: error: ISO C does not support ‘__int128’ types [-Werror=pedantic] __int128 int128; ^~~~~~~~ cc1: all warnings being treated as errors [2] Indeed I would like to discuss this distinct behavior of the mlx drivers, it is many time "-pedantic" caused problem, I will bring the discussion on separate thread.