From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=tpqW=J3=dpdk.org=dev-bounces@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,
	HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS
	autolearn=no autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 53EACC433ED
	for <dpdk-dev@archiver.kernel.org>; Fri, 30 Apr 2021 14:19:15 +0000 (UTC)
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by mail.kernel.org (Postfix) with ESMTP id C989F613EA
	for <dpdk-dev@archiver.kernel.org>; Fri, 30 Apr 2021 14:19:14 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C989F613EA
Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com
Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org
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?