From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id D28D4A0679 for ; Wed, 3 Apr 2019 21:27:55 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 881031B0F7; Wed, 3 Apr 2019 21:27:54 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id 2E2276C9B for ; Wed, 3 Apr 2019 21:27:53 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id BA70E221E6; Wed, 3 Apr 2019 15:27:52 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 03 Apr 2019 15:27:52 -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=mesmtp; bh=hQtz94DILzBf+ZAZM92ay2K4j7jWrx0sxS7Q6mDcirc=; b=eVO67JuvQRAj 3kxxb+m0VT/VhpP6sx49xDxoqGQT0mVh+3vkyQYpI3der8CqhRL/e5dHvMvL4DYO yX65IMhcJ/fZKsr/gmYQBIzDXlOa81jqiBFavCyGkC2boa/0bUE020uHSawEf5+g r2RtZWi4uLyAjpva6o1jlWhiudcdAoQ= 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=fm2; bh=hQtz94DILzBf+ZAZM92ay2K4j7jWrx0sxS7Q6mDci rc=; b=C8wIZd7u+fWbgnI92jqUtdjlxDKz0ueMFyMp8dIDaNs2NsDKLiGmkk13v iPIg+wBd7Tc3UJxaqM4I1m9g+ycBxV1uG/3kngnK1JOOlanPtH9ca/wD+8k9Q4AO k+VfZqOKbho1Fjv/exnycdta+9dOo0Ez8PcsCUsH0jWTbuTMf2ed6nMeOdJhzqP9 OnjDj2BnqQBplfFI+YOgxqPkf7H66t3GsFBaN1vnkr65/TMn7ek489Vek1j31KPq xIyGdZKcLjood4kYoRnLyJnPJyLeamoijsbaKXGfVcpqB1Cjrr1sTgVIHTd7E6+E FOj5Hz9z1YIDsppBkN6OUz6Mgq0rg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrtdefgdduudduucdltddurdeguddtrddttd dmucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnecujfgurhephffvufffkfgjfhgggfgtsehtufertddttddv necuhfhrohhmpefvhhhomhgrshcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjh grlhhonhdrnhgvtheqnecukfhppeejjedrudefgedrvddtfedrudekgeenucfrrghrrghm pehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvthenucevlhhush htvghrufhiiigvpedt X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 3CE22E49E6; Wed, 3 Apr 2019 15:27:50 -0400 (EDT) From: Thomas Monjalon To: "Eads, Gage" Cc: "dev@dpdk.org" , "olivier.matz@6wind.com" , "arybchenko@solarflare.com" , "Richardson, Bruce" , "Ananyev, Konstantin" , "gavin.hu@arm.com" , "Honnappa.Nagarahalli@arm.com" , "nd@arm.com" , "chaozhu@linux.vnet.ibm.com" , "jerinj@marvell.com" , "hemant.agrawal@nxp.com" Date: Wed, 03 Apr 2019 21:27:48 +0200 Message-ID: <1850366.0NedYqJ5gm@xps> In-Reply-To: <9184057F7FC11744A2107296B6B8EB1E542106DC@FMSMSX108.amr.corp.intel.com> References: <20190304205133.2248-1-gage.eads@intel.com> <2974113.GYloSpOT6o@xps> <9184057F7FC11744A2107296B6B8EB1E542106DC@FMSMSX108.amr.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v4 1/1] eal: add 128-bit compare exchange (x86-64 only) X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" Message-ID: <20190403192748.u0sINtKIwKGKvR0dlASMd46__sI1NQN9AwBp9uKej3c@z> 03/04/2019 21:21, Eads, Gage: > > 03/04/2019 19:34, Gage Eads: > > > This operation can be used for non-blocking algorithms, such as a > > > non-blocking stack or ring. > > > > > > Signed-off-by: Gage Eads > > > Reviewed-by: Honnappa Nagarahalli > > > --- > > > --- a/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h > > > +++ b/lib/librte_eal/common/include/arch/x86/rte_atomic_64.h > > > +/** > > > + * An atomic compare and set function used by the mutex functions. > > > + * (Atomically) Equivalent to: > > > + * if (*dst == *exp) > > > + * *dst = *src > > > + * else > > > + * *exp = *dst > > > + * > > > + * @note The success and failure arguments must be one of the > > > +__ATOMIC_* values > > > + * defined in the C++11 standard. For details on their behavior, > > > +refer to the > > > + * standard. > > > + * > > > + * @param dst > > > + * The destination into which the value will be written. > > > + * @param exp > > > + * Pointer to the expected value. If the operation fails, this memory is > > > + * updated with the actual value. > > > + * @param src > > > + * Pointer to the new value. > > > + * @param weak > > > + * A value of true allows the comparison to spuriously fail and allows the > > > + * 'exp' update to occur non-atomically (i.e. a torn read may occur). > > > + * Implementations may ignore this argument and only implement the > > strong > > > + * variant. > > > + * @param success > > > + * If successful, the operation's memory behavior conforms to this (or a > > > + * stronger) model. > > > + * @param failure > > > + * If unsuccessful, the operation's memory behavior conforms to this (or > > a > > > + * stronger) model. This argument cannot be __ATOMIC_RELEASE, > > > + * __ATOMIC_ACQ_REL, or a stronger model than success. > > > + * @return > > > + * Non-zero on success; 0 on failure. > > > + */ > > > +static inline int __rte_experimental > > > +rte_atomic128_cmp_exchange(rte_int128_t *dst, > > > + rte_int128_t *exp, > > > + const rte_int128_t *src, > > > + unsigned int weak, > > > + int success, > > > + int failure) > > > > I was thinking about keeping the doxygen in the generic file. > > Is it possible? > > > > We'd need to include the definition of rte_int128_t, so we'd also need either an ifdef on RTE_ARCH_64 or RTE_ARCH_X86_64 to protect 32-bit builds. That macro would prevent doxygen from parsing that section, unless we add a workaround like, for example: > > #if defined(RTE_ARCH_64) || defined(__DOXYGEN__) > > So the patch would look like the v3, with the declaration in generic/rte_atomic.h, but with that preprocessor change. If we change RTE_ARCH_X86_64 to RTE_ARCH_64, I'd add a note clarifying that it's only implemented for x86-64. What do you think? I would like to see the doc in the generic file and the implementation in the x86 file. I tried forward declaration of the typedef: struct rte_int128; typedef struct rte_int128 rte_int128_t; I don't why it does not work. So I'm trying to protect the declaration with #ifdef __DOXYGEN__