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 EAC12A0A05; Wed, 20 Jan 2021 11:32:37 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C685A140E97; Wed, 20 Jan 2021 11:32:37 +0100 (CET) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by mails.dpdk.org (Postfix) with ESMTP id C4749140E82 for ; Wed, 20 Jan 2021 11:32:36 +0100 (CET) IronPort-SDR: +44JxfvC/TzSl3k4xGCNIUKLnbYqBTHNPbtPMIvY2+lxN1ZTwOhFbZ9b9CLQXLGjgRgEGmqSlD JkcI2SZuM7SQ== X-IronPort-AV: E=McAfee;i="6000,8403,9869"; a="176511750" X-IronPort-AV: E=Sophos;i="5.79,360,1602572400"; d="scan'208";a="176511750" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jan 2021 02:32:33 -0800 IronPort-SDR: gxwRSn1OweuwP3us3rRozTL4hl/0rB5OWmndvBBg3meQjD46tTC1qDE8+daP2svNZ/IUdynxly wa9ffDF6gEAQ== X-IronPort-AV: E=Sophos;i="5.79,360,1602572400"; d="scan'208";a="350998998" Received: from dcrehan-mobl.ger.corp.intel.com (HELO [10.213.240.112]) ([10.213.240.112]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Jan 2021 02:32:30 -0800 To: Thomas Monjalon Cc: dev@dpdk.org, Timothy McDaniel , Jan Viktorin , Ruifeng Wang , Jerin Jacob , David Christensen , Bruce Richardson , Konstantin Ananyev , david.hunt@intel.com, chris.macnamara@intel.com References: <5237700.INpASENRAa@thomas> <95c0b120-3197-0e34-74b1-2ba76b116035@intel.com> <13958212.9hUD3U9ut9@thomas> From: "Burakov, Anatoly" Message-ID: <4a74146d-8a9c-a616-d798-198390752d2d@intel.com> Date: Wed, 20 Jan 2021 10:32:21 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <13958212.9hUD3U9ut9@thomas> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v17 03/11] eal: change API of power intrinsics 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 19-Jan-21 2:17 PM, Thomas Monjalon wrote: > 19/01/2021 12:23, Burakov, Anatoly: >> On 19-Jan-21 10:42 AM, Thomas Monjalon wrote: >>> 19/01/2021 11:29, Burakov, Anatoly: >>>> On 18-Jan-21 10:26 PM, Thomas Monjalon wrote: >>>>> 14/01/2021 15:46, Anatoly Burakov: >>>>>> +struct rte_power_monitor_cond { >>>>>> + volatile void *addr; /**< Address to monitor for changes */ >>>>>> + uint64_t val; /**< Before attempting the monitoring, the address >>>>>> + * may be read and compared against this value. >>>>> >>>>> "may" be read and compared? >>>>> Is there a case where there is no read and compare? >>>> >>>> Yes, if the mask is not set. >>> >>> If the mask is not set, the address is "read" anyway >>> or it is only "watched" for any change? >>> >>> Sorry the mechanism is really not clear to me. >>> >> >> The "value" is only used to avoid the sleep, i.e. to check if the write >> has already happened. We're waiting on *a write* rather than *a value*, >> so it's not equivalent to "wait until equal" call. It's more of a "sleep >> until something happens". > > Please make things explicit in doxygen. > The behaviour of each case should be explained crystal clear. > Thanks > > It is explained in the comments to `rte_power_monitor()` call. But OK, i'll add more clarification for the struct too. -- Thanks, Anatoly