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 0D727A04DD; Wed, 28 Oct 2020 04:26:42 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C33875A51; Wed, 28 Oct 2020 04:24:51 +0100 (CET) Received: from mail-oi1-f196.google.com (mail-oi1-f196.google.com [209.85.167.196]) by dpdk.org (Postfix) with ESMTP id 7F6D75947 for ; Wed, 28 Oct 2020 04:24:48 +0100 (CET) Received: by mail-oi1-f196.google.com with SMTP id k27so3571004oij.11 for ; Tue, 27 Oct 2020 20:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p/T97B4VW+a/NmlZiagwiw6Dl1ng0M40ajmIOW7vsUs=; b=K6m7V+wmY2LQ2ST6XZAtI698w8a6/5k5rU+LsWjjT6DpCfYlHLZQZE5JZAFTmCDdPP 7+bsDHyDfAowl1NA6I1v2SpGHzfm/H7122HWRwozT9t0C9QkjGNGm28tvu7OBVsDAJOq jjg0LhBODyAA6u3YxtkvXk3LNY42AlVO0NABQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=p/T97B4VW+a/NmlZiagwiw6Dl1ng0M40ajmIOW7vsUs=; b=erCMymDSNmSTYft0mzgyjvVpkVGWDs7wV/LR8DtorClSyXgpnEFwPocFX8XmpcpqYB N1kkNt2FqO1EmkudX1jrBUvWeSVkJD5EOA594YC7lcX/x54hzQjpIgS5Xop/ijP/NVg1 M0l/lQkkZVJrI/HLR7xfWvuHiGYQZYB6b0jXmTNn8pC68DYDkSpWLQui+JkqdHaXkFcU vP6MTeqm12ns+SDzXjxeSA3hU+2HgZ59NA9qtZ9Pu1HsO6OnKGnu0dWDRTJbaQm5qtJ8 zcIRaJ4JozTZ+BhXlBj8ATZnjjSEJ7qmoOy3i23bDGnrT47vkYnxTHm0RnG3pfZmxAYM zH6w== X-Gm-Message-State: AOAM5339Sxr373s094hLf0Wv3O8jP9U8Nd3CMx5W1Y9qrfwITrm/gTJ0 a2D33gE/6fhAeWMJ0QaHfZC3sQKdrtTggjoNJqFBLA== X-Google-Smtp-Source: ABdhPJyTk0BDzLJT+2vJ7gkGcCewik+7GLrrOvgTS+moW1SOMunJyHxNipJ9H6gMJjoZq+LBchKGzB+Oav2Dl7YUiDU= X-Received: by 2002:aca:38c6:: with SMTP id f189mr3845019oia.27.1603855487516; Tue, 27 Oct 2020 20:24:47 -0700 (PDT) MIME-Version: 1.0 References: <1603494392-7181-5-git-send-email-liang.j.ma@intel.com> <3195982.LjJ4KgG7bb@thomas> <1639360.KZQzHLtdKU@thomas> In-Reply-To: From: Ajit Khaparde Date: Tue, 27 Oct 2020 20:24:31 -0700 Message-ID: To: "Ananyev, Konstantin" Cc: Thomas Monjalon , "Ma, Liang J" , "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" , "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" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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 Tue, Oct 27, 2020 at 4:29 PM 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. I did not get this impression on reading it first time. Till you put it this way. The comment "if the masked value is already matching, abort" stumped me. > > Liang, Anatoly - feel free to correct me here, if I missed something. >