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 A85FFA0A05; Wed, 20 Jan 2021 12:11:22 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7CBCF140CCF; Wed, 20 Jan 2021 12:11:22 +0100 (CET) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by mails.dpdk.org (Postfix) with ESMTP id 45FF8140CCA for ; Wed, 20 Jan 2021 12:11:21 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id D2BE5580508; Wed, 20 Jan 2021 06:11:20 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Wed, 20 Jan 2021 06:11:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm3; bh= J1ToGopvNhYGEA5uWxQJOM/7HOKNu+CuUR8VaZ8PuCk=; b=CNMGn9OWJdYk4Otm OCE5EJ0Z092sdYQz6V0Zd8stQ3+6/AK7AmiwtWoNP4j0+ql4TVTYbeV2onCWbELN jcSvsfO2sAe93F5JbdhgzWE7IChVmwrPuOockdadWgQm5vRlP/bV66KxC3RqnTVI Bfd6rliBNssYDZDUZAZJeQMEki4rLI6RbcFuwXkYNhw8qWZHrnoYi1PwGSnn/4OE WjTMYA35e2mtQs7z3VeYQ/4IzNB6N0VyxBA7WgZ3kDJ+DgkoxXWWuPBSS30zTVg5 Ih5qyyjQS7Z5CKGp6fJCnTABVTHIJr2ad2oy6pRdvlZxhkW15IXsft39kjcLlik8 cE4qug== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=J1ToGopvNhYGEA5uWxQJOM/7HOKNu+CuUR8VaZ8Pu Ck=; b=rhz+rojUC4es9mUCS/g5x06j5aYEWsZ+bAYAg4L4MHFWf8x7Pj9U9CvmD /W+YG+GsVvVRJspfR/Ox0AobFJtcks3jFr4wIK4iTJ5fXwguU0gGKGrPlbFyIWKg tL0lgTalnxEOFaL7JsKxt0BUnpfgrsarHKvg70qXwqlcVluTHS9I8WCu/FW8yV0c RwBtMlK3++lyjEjLuPMXenCXPI5KlLSbj+Plx6iJe7sWn7dfgDM/pwsVFxBt75wU P7GwF6N64CwiD+cs7Dm8uguBAX3rOygxrdzLsfHFKNFvGn/ltvmyjizvGvIcR7nW c6qo1Kuqgn7WLBcLKCfox+Z1cp1mA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddvgddvjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih iivgepudenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 7F6C8240057; Wed, 20 Jan 2021 06:11:18 -0500 (EST) From: Thomas Monjalon To: "Burakov, Anatoly" 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, david.marchand@redhat.com, jerinj@marvell.com, ajit.khaparde@broadcom.com, honnappa.nagarahalli@arm.com, David Christensen Date: Wed, 20 Jan 2021 12:11:17 +0100 Message-ID: <3421789.b6iXB7q6zG@thomas> In-Reply-To: References: <8525653.OzbC6iP21P@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 20/01/2021 12:05, Burakov, Anatoly: > On 20-Jan-21 10:38 AM, Thomas Monjalon wrote: > > 20/01/2021 11:32, Burakov, Anatoly: > >> 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. > > > > Please avoid the word "may" in API description. > > > > This is what is explained in rte_power_monitor: > > " > > * Additionally, an `expected` 64-bit value and 64-bit mask are provided. If > > * mask is non-zero, the current value pointed to by the `p` pointer will be > > * checked against the expected value, and if they match, the entering of > > * optimized power state may be aborted. > > " > > > > Can we replace "may" by "will"? > > > > Yep, we can. However, the "may" part was intended to leave some wiggle > room for a different implementation, should the need arise, and i find > "will" to be needlessly prescriptive. Frankly, i do not see the need for > such a detailed description of what the API does under the hood, as long > as it's clear what its effects are. The main purpose is waiting for a > write. The mask is only used to check whether the expected write has > already happened by the time we're calling the API. Whether the CPU then > does or does not go to sleep is not really relevant IMO. I think it is relevant but I may be wrong. Any other opinions?