From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 37CE2A0546; Fri, 30 Apr 2021 16:19:14 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A66994014F; Fri, 30 Apr 2021 16:19:13 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by mails.dpdk.org (Postfix) with ESMTP id 3075E4013F for <dev@dpdk.org>; Fri, 30 Apr 2021 16:19:11 +0200 (CEST) IronPort-SDR: sgffQtfJl83oFuCybVbw4rSvE5xSNyED7T/eLphgGeiZMQ0IUGHbOAJsMhjKbBdMVxffrEte3z DSs2BUQJbdCg== X-IronPort-AV: E=McAfee;i="6200,9189,9970"; a="184419858" X-IronPort-AV: E=Sophos;i="5.82,262,1613462400"; d="scan'208";a="184419858" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Apr 2021 07:19:10 -0700 IronPort-SDR: R5Fo8yFsvo5mweAIN9KqEb+8TDFkbTuYxMs6iiO03v4PGPFGB50O5qXFLnqfWOSHEO8bntOVxu 6DxoOARXBu7g== X-IronPort-AV: E=Sophos;i="5.82,262,1613462400"; d="scan'208";a="527651339" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.20.97]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 30 Apr 2021 07:19:08 -0700 Date: Fri, 30 Apr 2021 15:19:05 +0100 From: Bruce Richardson <bruce.richardson@intel.com> To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com> Cc: "thomas@monjalon.net" <thomas@monjalon.net>, Ruifeng Wang <Ruifeng.Wang@arm.com>, David Marchand <david.marchand@redhat.com>, dev <dev@dpdk.org>, "jerinj@marvell.com" <jerinj@marvell.com>, nd <nd@arm.com> Message-ID: <YIwR2S6BCGntBKPd@bricha3-MOBL.ger.corp.intel.com> References: <20200424070741.16619-1-gavin.hu@arm.com> <2370044.79WzprfWfc@thomas> <AM5PR0802MB2465E347C949FE179FFC41AC9E5F9@AM5PR0802MB2465.eurprd08.prod.outlook.com> <20248566.ii5BvqWlRQ@thomas> <YIvLCnjYxeSMLnKj@bricha3-MOBL.ger.corp.intel.com> <DBAPR08MB5814D016A6A89B65EB69B5CB985E9@DBAPR08MB5814.eurprd08.prod.outlook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <DBAPR08MB5814D016A6A89B65EB69B5CB985E9@DBAPR08MB5814.eurprd08.prod.outlook.com> Subject: Re: [dpdk-dev] Use WFE for spinlock and ring X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> On Fri, Apr 30, 2021 at 01:41:22PM +0000, Honnappa Nagarahalli wrote: > <snip> > > > > > > > > > > > > > > > > > The rte_wait_until_equal_xxx APIs abstract the functionality > > > > > > > > of 'polling for a memory location to become equal to a given > > value'[1]. > > > > > > > > > > > > > > > > Use the API for the rte spinlock and ring implementations. > > > > > > > > With the wait until equal APIs being stable, changes will not impact > > ABI. > > > > > > > > > > > > > > Afaics, there is no ARM target with WFE enabled and we lost > > > > > > > ability to enable WFE support with removal of the make build > > system. > > > > > > > > > > > > WFE can be enabled with direct meson file change. > > > > > > WFE is not intended to be enabled by default. It can be enabled > > > > > > based on benchmarking result on hardware. > > > > > > > > > > > > > > $ git grep RTE_ARM_USE_WFE > > > > > > > config/arm/meson.build: ['RTE_ARM_USE_WFE', false], > > > > > > > lib/eal/arm/include/rte_pause_64.h:#ifdef RTE_ARM_USE_WFE > > > > > > > > > > > > > > How did you enable WFE to test this series? > > > > > > > > > > > > I modified meson file to test. > > > > > > Tests were also done with WFE disabled to make sure no > > > > > > degradation with > > > > > generic implementation. > > > > > > > > > > I don't understand the usage. > > > > > Which platform should use it? > > > > > > > > Platforms that implement WFE semantic (e.g. N1) can use. > > > > The user can enable this feature for power efficiency purpose. But > > > > there is something to note as described in commit message 1be7855d77 > > when the API was introduced. > > > > > > > > > Should it be a compile-time option? > > > > > > > > Yes, it should be a compile-time option. > > > > It can be configured via c_args meson option? > > > > > > +Cc Bruce for discussing how to enable such feature. > > > > > > The problem with c_args is that the application has no way to know. > > > > > Agree about c_args not being a great choice. Why does this need to be a > > compile-time option? Can runtime support not be detected in some > > manner? > The problem is inconsistency in performance on different Arm platforms. We had decided that each platform needs to enable it after some testing. Then it sounds like it does indeed need to be a build option. Does it need to be added to the meson_options.txt, or can it just be specified in cross-files and optionally via c_args?