From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 78884A0093; Thu, 28 May 2020 16:58:15 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 2C7601DBD0; Thu, 28 May 2020 16:58:14 +0200 (CEST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id CBEB91DBC9 for <dev@dpdk.org>; Thu, 28 May 2020 16:58:11 +0200 (CEST) IronPort-SDR: nlLtfE4Y6Ma3M7MVPN0jHQE4x0+6TESwVSRIr8ykiRPPES5FTsL/Edq41bUPgBwP9s7RJuSoZq zLQnBPfnhoxg== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 May 2020 07:58:09 -0700 IronPort-SDR: zUOOMzqLfn/f1IEWq1hwa/HTbCFoABtidc88jrWi6+2SeimIPfHGB2Hy2h0XPMWfeFyglkoZxl NCAbGQZvetrA== X-IronPort-AV: E=Sophos;i="5.73,445,1583222400"; d="scan'208";a="442976603" Received: from bricha3-mobl.ger.corp.intel.com ([10.251.88.36]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 28 May 2020 07:58:07 -0700 Date: Thu, 28 May 2020 15:58:04 +0100 From: Bruce Richardson <bruce.richardson@intel.com> To: "Burakov, Anatoly" <anatoly.burakov@intel.com> Cc: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>, "dev@dpdk.org" <dev@dpdk.org>, "Hunt, David" <david.hunt@intel.com>, "Ma, Liang J" <liang.j.ma@intel.com>, "Honnappa.Nagarahalli@arm.com" <Honnappa.Nagarahalli@arm.com> Message-ID: <20200528145804.GB924@bricha3-MOBL.ger.corp.intel.com> References: <cover.1590598121.git.anatoly.burakov@intel.com> <2772eb151ccba5cc17186e6161d8834176924753.1590598121.git.anatoly.burakov@intel.com> <BYAPR11MB3301B207DA0CAA780DA862169A8E0@BYAPR11MB3301.namprd11.prod.outlook.com> <be083ef0-cb21-3398-d604-86697cfe716b@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <be083ef0-cb21-3398-d604-86697cfe716b@intel.com> Subject: Re: [dpdk-dev] [RFC 1/6] eal: add power management intrinsics X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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 Thu, May 28, 2020 at 03:40:18PM +0100, Burakov, Anatoly wrote: > On 28-May-20 12:39 PM, Ananyev, Konstantin wrote: > > Hi Anatoly, > > > > > > > > Add two new power management intrinsics, and provide an implementation > > > in eal/x86 based on UMONITOR/UMWAIT instructions. The instructions > > > are implemented as raw byte opcodes because there is not yet widespread > > > compiler support for these instructions. > > > > > > The power management instructions provide an architecture-specific > > > function to either wait until a specified TSC timestamp is reached, or > > > optionally wait until either a TSC timestamp is reached or a memory > > > location is written to. The monitor function also provides an optional > > > comparison, to avoid sleeping when the expected write has already > > > happened, and no more writes are expected. > > > > Recently ARM guys introduced new generic API > > for similar (as I understand) purposes: rte_wait_until_equal_(16|32|64). > > Probably would make sense to unite both APIs into something common > > and HW transparent. > > Konstantin > > Hi Konstantin, > > That's not really similar purpose. This is monitoring a cacheline for > writes, not waiting on a specific value. The "expected" value is there as > basically a hack to get around the race condition due to the fact that by > the time you enter monitoring state, the write you're waiting for may have > already happened. > Rather than the "expected" value, is it not more useful for a general API to check for the existing value? Since we are awaiting writes, we may not know what new value will be written, but we do know what the value is now, and can just check that it's not been changed. Regards, /Bruce