From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
by inbox.dpdk.org (Postfix) with ESMTP id 78A95A0A05;
Wed, 20 Jan 2021 11:38:56 +0100 (CET)
Received: from [217.70.189.124] (localhost [127.0.0.1])
by mails.dpdk.org (Postfix) with ESMTP id 4E375140D12;
Wed, 20 Jan 2021 11:38:56 +0100 (CET)
Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com
[66.111.4.224]) by mails.dpdk.org (Postfix) with ESMTP id 33C87140E9D
for <dev@dpdk.org>; Wed, 20 Jan 2021 11:38:54 +0100 (CET)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42])
by mailnew.nyi.internal (Postfix) with ESMTP id 9D668580639;
Wed, 20 Jan 2021 05:38:53 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163])
by compute2.internal (MEProxy); Wed, 20 Jan 2021 05:38:53 -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=
rO2c4ZTjSYuAQ+Af4wINFc4BiQR5YfDgrwn/KSw5d7o=; b=c6xhUCaqfF6GZoT5
6glt3uVdcLNU+APB9WnOMjWd4leXf+srpGhr7CsIsvs8NPw4i+jwUUNM3wcNTkv3
1jTDlPiYsO7LvBvdO2jZRskQNfGbda6i3D2moiXcxFN+PIM3W2q+0jAHsmi4LvVl
tfX1zCg5YEi3VUNPm4dYVr5+ldBW37oEs2sLSZluELGplHEN/ntMRWyUwcSeyGVb
nuVZKkSwnVW68QtDb/jwVfN+ElnE1TjONNmNOhoz9ek7uKxm/24jykjFL5QX8P07
0Iq6LgBIvDlxndbgbouFVS1sJnlqN8cEc/W3rFWRof/5B6d5iJN9teyyTPghhOwG
rysbwQ==
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=rO2c4ZTjSYuAQ+Af4wINFc4BiQR5YfDgrwn/KSw5d
7o=; b=J5qx0Ung8UYKj+PVJa9C9zv5O/JYEYjaBGv8Ymy4RpfrmZVNEaj//sr7I
/bBRE8KXwLTWVtRnDElj/H2nnHAgmwuofDK+fj7vO5g+j3g39AmmpU84j2bKV3H9
1EGR945oQW1Q4bdWWkB3zFRu7+IuGqnehmImO9ZscYd6ohb+LrXwYZW7+OVPen2k
371f+k8G7MHW74jVz/6MtJ35aIZ+AiMYu6bHqTS9gPD3gH0/rwjmFV/S9lanIy6Z
85NK1bGOjfhOShAGxGMsXuirkNy/hM5r5eOs4HlC15EYG0sq3+8xSkqBB0TOfNS+
v091utEaaq0VfnM2hrr437kKtwH4A==
X-ME-Sender: <xms:PAgIYIxc4DKzLS5UE6FxsN1YSUia913-1OloIuxTTyMOetaY_hfujQ>
<xme:PAgIYMRLsz3g8_XJSbXrTcmKuqf8-jPwxBG5eNwY4hmM5y27Z1Rr4xgcM-tgmVduK
BwgxYtlN6l53BHkug>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddvgddulecutefuodetggdotefrodftvf
curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs
ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf
frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei
iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih
iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho
nhdrnhgvth
X-ME-Proxy: <xmx:PAgIYKWyeSPv-zsACmKYndllCUlBgiB2jz39w5gsHclG5v6CAjy1Dg>
<xmx:PAgIYGi6UHztCuHEtPcegw6stw6Gbk_ExVitVdIombpTSxbP18lNgw>
<xmx:PAgIYKCS_Lln6le3H2uJtl35bbFXKZLL9q2bMyAkJEtPcUs1Zo1Y1A>
<xmx:PQgIYG2Ovv94WBY9mKjdtyUyAlFNTI6qS56c8mzixSZEpz0VKT7YCQ>
Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184])
by mail.messagingengine.com (Postfix) with ESMTPA id A8D89108005C;
Wed, 20 Jan 2021 05:38:51 -0500 (EST)
From: Thomas Monjalon <thomas@monjalon.net>
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Cc: dev@dpdk.org, Timothy McDaniel <timothy.mcdaniel@intel.com>,
Jan Viktorin <viktorin@rehivetech.com>, Ruifeng Wang <ruifeng.wang@arm.com>,
Jerin Jacob <jerinj@marvell.com>, David Christensen <drc@linux.vnet.ibm.com>,
Bruce Richardson <bruce.richardson@intel.com>,
Konstantin Ananyev <konstantin.ananyev@intel.com>, david.hunt@intel.com,
chris.macnamara@intel.com
Date: Wed, 20 Jan 2021 11:38:50 +0100
Message-ID: <8525653.OzbC6iP21P@thomas>
In-Reply-To: <4a74146d-8a9c-a616-d798-198390752d2d@intel.com>
References: <cover.1610473000.git.anatoly.burakov@intel.com>
<13958212.9hUD3U9ut9@thomas> <4a74146d-8a9c-a616-d798-198390752d2d@intel.com>
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 <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>
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"?