From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 3B2F8A04DD; Wed, 28 Oct 2020 13:24:46 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7F172CA35; Wed, 28 Oct 2020 13:24:14 +0100 (CET) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 1DABBC9F0 for ; Wed, 28 Oct 2020 13:24:12 +0100 (CET) IronPort-SDR: HRX6hfPIQmVSZpEO0jM37AxdO8uaJj06EJUupcimirFusmYFctfAIMmFPouytIE+lzSjRlG9PT +1dbY7dZxfHQ== X-IronPort-AV: E=McAfee;i="6000,8403,9787"; a="167467666" X-IronPort-AV: E=Sophos;i="5.77,426,1596524400"; d="scan'208";a="167467666" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Oct 2020 05:24:11 -0700 IronPort-SDR: p8iu824qKfSg3lrmDsa7oWUIHgjbb7PftZrCCRE5+fu+gySoMqnuNQiXzGxpCg4QSEV41OSBOV G9rEnpF/B1TQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,426,1596524400"; d="scan'208";a="424707200" Received: from irvmail001.ir.intel.com ([163.33.26.43]) by fmsmga001.fm.intel.com with ESMTP; 28 Oct 2020 05:24:05 -0700 Received: from sivswdev09.ir.intel.com (sivswdev09.ir.intel.com [10.237.217.48]) by irvmail001.ir.intel.com (8.14.3/8.13.6/MailSET/Hub) with ESMTP id 09SCO5MI007124; Wed, 28 Oct 2020 12:24:05 GMT Received: from sivswdev09.ir.intel.com (localhost [127.0.0.1]) by sivswdev09.ir.intel.com with ESMTP id 09SCO43n030983; Wed, 28 Oct 2020 12:24:04 GMT Received: (from lma25@localhost) by sivswdev09.ir.intel.com with LOCAL id 09SCO3U3030962; Wed, 28 Oct 2020 12:24:03 GMT Date: Wed, 28 Oct 2020 12:24:03 +0000 From: "Liang, Ma" To: "Ananyev, Konstantin" Cc: Thomas Monjalon , "dev@dpdk.org" , "Burakov, Anatoly" , "viktorin@rehivetech.com" , "Zhang, Qi Z" , "ruifeng.wang@arm.com" , "Xing, Beilei" , "Guo, Jia" , "Yang, Qiming" , "Wang, Haiyue" , "Richardson, Bruce" , "Hunt, David" , "jerinjacobk@gmail.com" , "nhorman@tuxdriver.com" , "McDaniel, Timothy" , "Eads, Gage" , "drc@linux.vnet.ibm.com" , Andrew Rybchenko , "Yigit, Ferruh" , "jerinj@marvell.com" , "hemant.agrawal@nxp.com" , "viacheslavo@nvidia.com" , "matan@nvidia.com" , "ajit.khaparde@broadcom.com" , "rahul.lakkireddy@chelsio.com" , "johndale@cisco.com" , "xavier.huwei@huawei.com" , "shahafs@nvidia.com" , "sthemmin@microsoft.com" , "g.singh@nxp.com" , "rmody@marvell.com" , "maxime.coquelin@redhat.com" , "david.marchand@redhat.com" Message-ID: <20201028122403.GB29706@sivswdev09.ir.intel.com> References: <1603494392-7181-5-git-send-email-liang.j.ma@intel.com> <3195982.LjJ4KgG7bb@thomas> <1639360.KZQzHLtdKU@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [PATCH v9 04/10] ethdev: add simple power management API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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 27 Oct 16:29, Ananyev, Konstantin wrote: > > > > -----Original Message----- > > From: Thomas Monjalon > > Sent: Tuesday, October 27, 2020 6:31 PM > > To: Ma, Liang J ; Ananyev, Konstantin > > Cc: dev@dpdk.org; Burakov, Anatoly ; viktorin@rehivetech.com; Zhang, Qi Z ; > > ruifeng.wang@arm.com; Xing, Beilei ; Guo, Jia ; Yang, Qiming ; > > Wang, Haiyue ; Richardson, Bruce ; Hunt, David ; > > jerinjacobk@gmail.com; nhorman@tuxdriver.com; McDaniel, Timothy ; Eads, Gage > > ; drc@linux.vnet.ibm.com; Andrew Rybchenko ; Yigit, Ferruh > > ; jerinj@marvell.com; hemant.agrawal@nxp.com; viacheslavo@nvidia.com; matan@nvidia.com; > > ajit.khaparde@broadcom.com; rahul.lakkireddy@chelsio.com; johndale@cisco.com; xavier.huwei@huawei.com; shahafs@nvidia.com; > > sthemmin@microsoft.com; g.singh@nxp.com; rmody@marvell.com; maxime.coquelin@redhat.com; david.marchand@redhat.com > > Subject: Re: [dpdk-dev] [PATCH v9 04/10] ethdev: add simple power management API > > > > 27/10/2020 18:43, Ananyev, Konstantin: > > > > 27/10/2020 12:15, Liang, Ma: > > > > > > > --- a/lib/librte_ethdev/rte_ethdev.h > > > > > > > +++ b/lib/librte_ethdev/rte_ethdev.h > > > > > > > +/** > > > > > > > + * Retrieve the wake up address for the receive queue. > > > > > > > > > > > > I guess how this function should be used, > > > > > > but a bit more explanations would not hurt here. > > > > > agree > > > > > > > + * > > > > > > > + * @param port_id > > > > > > > + * The port identifier of the Ethernet device. > > > > > > > + * @param queue_id > > > > > > > + * The Rx queue on the Ethernet device for which information will be > > > > > > > + * retrieved. > > > > > > > + * @param wake_addr > > > > > > > + * The pointer to the address which will be monitored. > > > > > > > > > > > > This function does not make the address monitored, right? > > > > > This function only get the target wakeup address. that does not monitor this address. > > > > > > > > > > > > > + * @param expected > > > > > > > + * The pointer to value to be expected when descriptor is set. > > > > > > > > > > > > Not sure we should restrict it to a "descriptor". > > > > > actully that is not limited to a descriptor, any writeback content should work. > > > > > > > > > > > > Expecting a value or some bits looks too much restrictive. > > > > > > I understand it probably fits well for Intel NICs, > > > > > > but in the general case, we can imagine that any change > > > > > > in a byte array could be a wake up signal. > > > > > > > > > > this parameter doesn not limited user how to use it. > > > > > In fact, current design can support any bits change within 64 bits content. > > > > > > > > How the driver can specify that any value change should be monitored? > > > > I understand that it is only a value/mask pair, > > > > it does not give room for "any value". > > > > > > As I can read the code, value=0, mask=0 will provide you with 'any value'. > > > Though it would mean that rte_power_monitor() will *always* go into sleep, > > > so not sure what will be there any practical usage for such case. > > > > I think what is missing is to allow waking up when the value > > of a byte array is changing, without specifiying any value. > > > I think it will always wakeup on any write to wait_addr. > What you control with value/mask pair - when we should go to sleep. > In other words: > ret = rte_eth_get_wake_addr(port, queue, &wait_addr, &value, &mask, ....); > > mask==0: always go to sleep, wakeup at any store to wait_addr. > mask!=0: go to sleep only if (*wait_addr & mask) == value, wakeup at any store to wait_addr. > > Liang, Anatoly - feel free to correct me here, if I missed something. mask and expected value is used to prevent race condition with NIC. there is a interval between code get target address and issue umwait action. therefore, the mask is a selector of the bits, if the current value & mask already == the expected value just before issue the umwait, that mean that address is no longer useful for umwait because of DMA has happend. then the code path is abort and back to normal logic.