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 459FAA04B4; Fri, 8 Nov 2019 19:36:59 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5D7841C2A3; Fri, 8 Nov 2019 19:36:58 +0100 (CET) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id 810991C29F for ; Fri, 8 Nov 2019 19:36:56 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Nov 2019 10:36:55 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,282,1569308400"; d="scan'208";a="193244946" Received: from irsmsx152.ger.corp.intel.com ([163.33.192.66]) by orsmga007.jf.intel.com with ESMTP; 08 Nov 2019 10:36:54 -0800 Received: from irsmsx155.ger.corp.intel.com (163.33.192.3) by IRSMSX152.ger.corp.intel.com (163.33.192.66) with Microsoft SMTP Server (TLS) id 14.3.439.0; Fri, 8 Nov 2019 18:36:53 +0000 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.252]) by irsmsx155.ger.corp.intel.com ([169.254.14.193]) with mapi id 14.03.0439.000; Fri, 8 Nov 2019 18:36:52 +0000 From: "Ananyev, Konstantin" To: Thomas Monjalon CC: David Marchand , "dev@dpdk.org" , "nd@arm.com" , Gavin Hu , "Mcnamara, John" , "Kovacevic, Marko" , Jerin Jacob , Jan Viktorin Thread-Topic: [PATCH v13 2/5] eal: add the APIs to wait until equal Thread-Index: AQHVlbNd73fGjCsb40qrF5PYyLu+BKeBeVbAgAAHOYCAABozAA== Date: Fri, 8 Nov 2019 18:36:52 +0000 Message-ID: <2601191342CEEE43887BDE71AB97725801A8C83A2B@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> <1931245.p08n36Xx7L@xps> In-Reply-To: <1931245.p08n36Xx7L@xps> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMmY3OTUyODctOWNlMC00OTdmLWIyZjQtY2M3NDJiOTllN2Q3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiRGpIUFYrUUJheTlENVhkXC9WS08xNDg4MktcL0w0N1MwYVRQXC9YZ1M3aVAxdlVUbGRDTnBKbCs2djJWcFJ2ZnpPNCJ9 x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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" > -----Original Message----- > From: Thomas Monjalon > Sent: Friday, November 8, 2019 5:00 PM > To: Ananyev, Konstantin > Cc: David Marchand ; dev@dpdk.org; nd@arm.com;= Gavin Hu ; Mcnamara, John > ; Kovacevic, Marko ; = Jerin Jacob ; Jan Viktorin > > Subject: Re: [PATCH v13 2/5] eal: add the APIs to wait until equal >=20 > 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 =3D=3D __ATOMIC_ACQUIRE || memorder =3D=3D __ATOMIC= _RELAXED); > > > + > > > + /* > > > + * Atomic exclusive load from addr, it returns the 64-bit content o= f > > > + * *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 =3D=3D __ATOMIC_RELAXED) { \ > > > + asm volatile("ldxr %x[tmp], [%x[addr]]" \ > > > + : [tmp] "=3D&r" (dst) \ > > > + : [addr] "r"(src) \ > > > + : "memory"); \ > > > + } else { \ > > > + asm volatile("ldaxr %x[tmp], [%x[addr]]" \ > > > + : [tmp] "=3D&r" (dst) \ > > > + : [addr] "r"(src) \ > > > + : "memory"); \ > > > + } } > > > + > > > + __LOAD_EXC_64(addr, value, memorder) > > > + if (value !=3D expected) { > > > + __SEVL() > > > + do { > > > + __WFE() > > > + __LOAD_EXC_64(addr, value, memorder) > > > + } while (value !=3D expected); > > > + } > > > +} > > > +#undef __LOAD_EXC_64 > > > + > > > +#undef __SEVL > > > +#undef __WFE > > > > Personally I don't see how these define/undef are better then inline fu= nctions... >=20 > 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. >=20 > > Again I suppose they might be re-used in future some other ARM specific= low-level primitvies. >=20 > Do this low-level routines _LOAD_EXC_ need to be exposed in EAL for re-us= e? About load_exc don't know for sure... Though as I can see wfe/sevl are used here: http://patchwork.dpdk.org/patch/61779/ Might be it is possible to reuse these functions/macros... But again, I am not arm expert, would be interested to know what arm guys t= hink. >=20 > > My preference would be to keep them as inline function - much cleaner c= ode. > > But as I don't develop for/use, I wouldn't insist and let you and arm g= uys to decide. >=20 >=20