From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 158A6A0546; Fri, 30 Apr 2021 11:17:10 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 80BFD4014F; Fri, 30 Apr 2021 11:17:09 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mails.dpdk.org (Postfix) with ESMTP id 171714013F for ; Fri, 30 Apr 2021 11:17:07 +0200 (CEST) IronPort-SDR: TlG3VrgWN7ZWldkNvrwNbfiKkK5Ljt6mhNfTKkDvXYoLkzySItTDHxAEhg4Ysxv4Oa+NHaum8G z0Ci4/yrI3YA== X-IronPort-AV: E=McAfee;i="6200,9189,9969"; a="196793657" X-IronPort-AV: E=Sophos;i="5.82,262,1613462400"; d="scan'208";a="196793657" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Apr 2021 02:17:06 -0700 IronPort-SDR: KzaFWRr6Ueq1/0GmuQgdMk7UIgtaLLTibCItZx7sbO4a6Q9FeP/3PmjdEFfffqAyDwUwXL/ax5 Rf1gNmuf6WlA== X-IronPort-AV: E=Sophos;i="5.82,262,1613462400"; d="scan'208";a="431337434" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.20.97]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 30 Apr 2021 02:17:03 -0700 Date: Fri, 30 Apr 2021 10:16:58 +0100 From: Bruce Richardson To: Thomas Monjalon Cc: Ruifeng Wang , David Marchand , dev , "jerinj@marvell.com" , nd , Honnappa Nagarahalli Message-ID: References: <20200424070741.16619-1-gavin.hu@arm.com> <2370044.79WzprfWfc@thomas> <20248566.ii5BvqWlRQ@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20248566.ii5BvqWlRQ@thomas> 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, Apr 29, 2021 at 05:20:05PM +0200, Thomas Monjalon wrote: > 29/04/2021 16:28, Ruifeng Wang: > > From: Thomas Monjalon > > > 28/04/2021 11:30, Ruifeng Wang: > > > > From: David Marchand > > > > > On Sun, Apr 25, 2021 at 7:57 AM Ruifeng Wang > > > > > wrote: > > > > > > > > > > > > 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?