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 1405EA04BA; Mon, 11 Nov 2019 06:12:01 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1BB7C2142; Mon, 11 Nov 2019 06:12:00 +0100 (CET) Received: from mail-il1-f194.google.com (mail-il1-f194.google.com [209.85.166.194]) by dpdk.org (Postfix) with ESMTP id 2F956235 for ; Mon, 11 Nov 2019 06:11:58 +0100 (CET) Received: by mail-il1-f194.google.com with SMTP id q1so10249422ile.13 for ; Sun, 10 Nov 2019 21:11:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1NM11cb93cMUczJhI+86Migko6L0FuivQgbLcPl1yDk=; b=FT0asTBE+s1L/2zMbe4dNbDDy87REBNJmmEnf7D5eh1dg//2eHWwX9Nxebi+8lVDt8 VGKrhTb6IfHl2mqveJvIkjv/tOBNd28KRTogWs6p8fxY2DtmF3bQ6/hObFiye/sr8OPx QAMFBJOACNm/rg3dgbjNiRsIFVZ7nWeVyOp2gmHQ5fwoGlVlGQOCW7Owpfk+4zFoAqSj OtpCEtpx5+opH2U9TAdHaRIkQvC3Rtj9H7RgNI2/DCjwZVDqm73c8TgM5Pva0PMjUN7X 7VXJpDvk8rY92fwXDoOtSyFXKBrozKgwmUHxYysbuYT7F/rDJBa4LP3igyWxZUSq3OCl GytQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1NM11cb93cMUczJhI+86Migko6L0FuivQgbLcPl1yDk=; b=fhEfLyP4uPFWsQQ0UmhHN/8NWh/cfv2n6qyrUelmMlJZEUogILhY4EcB2aqCDnIgAp gRQYWIGYKLrqSZCKu1aOQw6dHIzH+fqzJQRAF0H2EuTBOx6Ae6NN77fmJMe5yhuncUhD mK/GRKFDHWfNqhCgwjBhY9v/1G7+7OirOc39WCFmC4V3kRak3cea9b95qsS38Rau+8Dd CR9snW2Ua4I5b8cGRb5nIsTAzhEPeat2Hs4wN6IDy4u3dPwuEq4Igg2/+jOU/DESRpOr +2pR//UDcK1+O7oVoT3iQ86CeC8lwQArt5ENqyidRFyja3AuITDgsKL0oKDsd6jTNk59 gHJg== X-Gm-Message-State: APjAAAXioLnhhLmRmleCFjT2W4ddiJd07QXPF4WZTLf8PBfGB0oDdCZE 8huylLgZ1gqdC51YVxBMlqa6juSJqrYi7zgp9mY= X-Google-Smtp-Source: APXvYqyOMwAeNu0wXdfPiftNdTXtwpmQx1umL55wPs2qTgkXcWwV4ttA00LcCihkt2/2zK39AOlJxAnClBRZ7MA/hUA= X-Received: by 2002:a92:1612:: with SMTP id r18mr26826228ill.60.1573449117200; Sun, 10 Nov 2019 21:11:57 -0800 (PST) MIME-Version: 1.0 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> <2601191342CEEE43887BDE71AB97725801A8C83A2B@IRSMSX104.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB97725801A8C83A2B@IRSMSX104.ger.corp.intel.com> From: Jerin Jacob Date: Mon, 11 Nov 2019 10:41:40 +0530 Message-ID: To: "Ananyev, Konstantin" Cc: Thomas Monjalon , David Marchand , "dev@dpdk.org" , "nd@arm.com" , Gavin Hu , "Mcnamara, John" , "Kovacevic, Marko" , Jerin Jacob , Jan Viktorin Content-Type: text/plain; charset="UTF-8" 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" On Sat, Nov 9, 2019 at 12:07 AM Ananyev, Konstantin wrote: > > > > > -----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 > > > > 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? > > 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 think. Considering WFE has a requirement on using load_exec on ARM so IMO, it makes sense to expose load_exec in conjunction with wfe/sevl to use it properly. > > > > > > 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. > > > > >