From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 744E8A04B4; Fri, 8 Nov 2019 18:00:19 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B35211C2EF; Fri, 8 Nov 2019 18:00:18 +0100 (CET) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 190781C2EA for ; Fri, 8 Nov 2019 18:00:17 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6399621E56; Fri, 8 Nov 2019 12:00:16 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Fri, 08 Nov 2019 12:00:16 -0500 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=k8WLDa6HpxM6rLjxGbDg9W1dk/xXl8aTFg7hrW2FEaY=; b=A4Ox/elcc6TX vDKIApoMG8YGxpyRV9c/na3uibt8oM8OFWIbZIPfgFkfuj9eYskTLyBzYOabWQf8 qftZ/54wK5KnZPsUGaNNIl46mhiUqRsU+19vAzQwPgmw55UCq+XwsbG4GjI6ARvo BvtTGKWLNChwj91XFBpmEcUgqg2mLJ8= 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=fm1; bh=k8WLDa6HpxM6rLjxGbDg9W1dk/xXl8aTFg7hrW2FE aY=; b=OnUmXZnl1UiNd7waLOoDd2BPSoxk7CXnk52dUPJO5RB/cTiiCQjvBbSFo rnl8psHImy/nKTbh5nUp/GtZsDJUEDAlGNiJyxSEzo1aAUqWIk6Wz1kVABg1JcNi qncbBL6jRrZ1peW+13IMlIoZyDnU7W916E9H7pb/Gxidr+PHfP9NRpKliTRVViCR Q0mfTzuTQV4fFiog1ckv3dtlxKgrA32tcNzM8w3TWFTO0Jc4qV31uvz2NtXAcLap DnbATxiWJT4Cg5PwGTtDtaPyv5mhNb+yhg4DXI3TDaUvtmL1p9I9ERLjTqfY3jQE UKtSNU0L0XxqWkcCMrQVeTVSE8N3w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddvuddgleejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecuff homhgrihhnpehhuhgrrhhmrdgtohhmnecukfhppeejjedrudefgedrvddtfedrudekgeen ucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth enucevlhhushhtvghrufhiiigvpedt 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 DBE4B306005E; Fri, 8 Nov 2019 12:00:12 -0500 (EST) From: Thomas Monjalon To: "Ananyev, Konstantin" Cc: David Marchand , "dev@dpdk.org" , "nd@arm.com" , Gavin Hu , "Mcnamara, John" , "Kovacevic, Marko" , Jerin Jacob , Jan Viktorin Date: Fri, 08 Nov 2019 18:00:11 +0100 Message-ID: <1931245.p08n36Xx7L@xps> In-Reply-To: <2601191342CEEE43887BDE71AB97725801A8C833FA@IRSMSX104.ger.corp.intel.com> References: <1561911676-37718-1-git-send-email-gavin.hu@arm.com> <1573162528-16230-3-git-send-email-david.marchand@redhat.com> <2601191342CEEE43887BDE71AB97725801A8C833FA@IRSMSX104.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v13 2/5] eal: add the APIs to wait until equal 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" 08/11/2019 17:38, Ananyev, Konstantin: > > From: Gavin Hu > > +static __rte_always_inline void > > +rte_wait_until_equal_64(volatile uint64_t *addr, uint64_t expected, > > + int memorder) > > +{ > > + uint64_t value; > > + > > + assert(memorder == __ATOMIC_ACQUIRE || memorder == __ATOMIC_RELAXED); > > + > > + /* > > + * Atomic exclusive load from addr, it returns the 64-bit content of > > + * *addr while making it 'monitored',when it is written by someone > > + * else, the 'monitored' state is cleared and a event is generated > > + * implicitly to exit WFE. > > + */ > > +#define __LOAD_EXC_64(src, dst, memorder) { \ > > + if (memorder == __ATOMIC_RELAXED) { \ > > + asm volatile("ldxr %x[tmp], [%x[addr]]" \ > > + : [tmp] "=&r" (dst) \ > > + : [addr] "r"(src) \ > > + : "memory"); \ > > + } else { \ > > + asm volatile("ldaxr %x[tmp], [%x[addr]]" \ > > + : [tmp] "=&r" (dst) \ > > + : [addr] "r"(src) \ > > + : "memory"); \ > > + } } > > + > > + __LOAD_EXC_64(addr, value, memorder) > > + if (value != expected) { > > + __SEVL() > > + do { > > + __WFE() > > + __LOAD_EXC_64(addr, value, memorder) > > + } while (value != expected); > > + } > > +} > > +#undef __LOAD_EXC_64 > > + > > +#undef __SEVL > > +#undef __WFE > > Personally I don't see how these define/undef are better then inline functions... The benefit it to not pollute the API namespace with some functions which are used only locally. After using a macro, it disappears with #undef. > Again I suppose they might be re-used in future some other ARM specific low-level primitvies. Do this low-level routines _LOAD_EXC_ need to be exposed in EAL for re-use? > My preference would be to keep them as inline function - much cleaner code. > But as I don't develop for/use, I wouldn't insist and let you and arm guys to decide.