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 6C437A04B0; Sat, 24 Oct 2020 22:40:12 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C77E2B55; Sat, 24 Oct 2020 22:40:10 +0200 (CEST) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by dpdk.org (Postfix) with ESMTP id 1DB609E3 for ; Sat, 24 Oct 2020 22:40:08 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 96F33580117; Sat, 24 Oct 2020 16:40:03 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Sat, 24 Oct 2020 16:40:03 -0400 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=fm2; bh= FXJtfCbSO67BLCEAN7hsi+Ot6MV6MynQSgoK9MhL4tY=; b=rDktyciAV2wqBlNs 5Nt50btDw13dXoH6LDk/636W4Ow3ObaSd4BMxhJTTyx1iAKqLRLL+Rb48wN5VuDj Xk5XbsWUd/gBDCxP9C5++fqp1UbEeeGtWc8w0HhKlrZxZaWfQe9pKXZkK8GzIPgM KRjZVLCX7Xz0HBlwyq8V/DFzgvlnpUKj/iPUbN44sk0gwTfLIzRJo9U8ioIwGh4Z A8Iqgd2mQu1kBGW3Sa5RSGhVi4N6FNKXzg9/sYT8B+H1kt+C1i33S/zbtCIF8Y+e /fl1hfz3h/p3+asXjQlRQZKsU4QisFdTs0J9nPD/33Co0hVazKmQniBjDPduX9hh f0L0Sg== 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=FXJtfCbSO67BLCEAN7hsi+Ot6MV6MynQSgoK9MhL4 tY=; b=rtsPc9/ABHIK+OY2w6mlQEqUrCMKiSegUtKaiZM2m09Ct8CbKTlIeVMR4 ZO/0Sz1xWzkKJ2UtS2UW61vQc6lOvSrTLVqQP5qwVEpzfV1iLuHZutFks4RlkTec ghdpKjjLfZAwXKJPP098+P0E/ToSNBdyQsGJyPfQUMDlqEuHlqxaICFpPYvXkjm3 mcoJXCdVn3pmx6ua6yFiSDQiRtdF1S1pcWQjNNlhhM35YFK7YfmVUS+Yr+v739Hu FwpkDIkkwPuIRy+Wi9MowX6t06U8Z0cVvzNZXvv9jbOQhiSmElpJrtN3ZA3FKhL+ 3NS6SLl2pb3GnFbJlBI9VfXgOfz9g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrkedvgdduhedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght 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 616503280064; Sat, 24 Oct 2020 16:39:57 -0400 (EDT) From: Thomas Monjalon To: Liang Ma Cc: dev@dpdk.org, anatoly.burakov@intel.com, viktorin@rehivetech.com, qi.z.zhang@intel.com, ruifeng.wang@arm.com, beilei.xing@intel.com, jia.guo@intel.com, qiming.yang@intel.com, haiyue.wang@intel.com, bruce.richardson@intel.com, konstantin.ananyev@intel.com, david.hunt@intel.com, jerinjacobk@gmail.com, nhorman@tuxdriver.com, timothy.mcdaniel@intel.com, gage.eads@intel.com, drc@linux.vnet.ibm.com, Andrew Rybchenko , ferruh.yigit@intel.com, 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 Date: Sat, 24 Oct 2020 22:39:55 +0200 Message-ID: <2168123.9p5K5TOhLB@thomas> In-Reply-To: <1603494392-7181-5-git-send-email-liang.j.ma@intel.com> References: <1603494392-7181-5-git-send-email-liang.j.ma@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 24/10/2020 01:06, Liang Ma: > Add a simple API to allow getting address of next RX descriptor from the > PMD, as well as release notes information. > > Signed-off-by: Liang Ma > Signed-off-by: Anatoly Burakov > Acked-by: Konstantin Ananyev You keep forgetting Cc ethdev maintainers (it is automatic when using --cc-cmd devtools/get-maintainer.sh). As a result we still don't have any feedback from Ferruh and Andrew. And I believe such API requires having feedback from maintainers of other NIC drivers. I tried to explain this concern already in email and community meetings, but I see no progress. Below are my comments. > --- a/doc/guides/rel_notes/release_20_11.rst > +++ b/doc/guides/rel_notes/release_20_11.rst > @@ -139,6 +139,11 @@ New Features > Hairpin Tx part flow rules can be inserted explicitly. > New API is added to get the hairpin peer ports list. > > +* **ethdev: add 1 new EXPERIMENTAL API for PMD power management.** The guidelines at the top of the file say using past tense. No need to mention it is experimental as any new API. > + > + * ``rte_eth_get_wake_addr()`` > + * add new eth_dev_ops ``get_wake_addr`` No need to mention the dev_ops in the release notes. Better to explain what it brings from an user perspective. > --- 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. > + * > + * @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? > + * @param expected > + * The pointer to value to be expected when descriptor is set. Not sure we should restrict it to a "descriptor". 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. > + * @param mask > + * The pointer to comparison bitmask for the expected value. > + * @param data_sz > + * The pointer to data size for the expected value and comparison bitmask. It is not clear that above 4 parameters are filled by the driver. > + * > + * @return > + * - 0: Success. > + * -ENOTSUP: Operation not supported. > + * -EINVAL: Invalid parameters. > + * -ENODEV: Invalid port ID. > + */ > +__rte_experimental > +int rte_eth_get_wake_addr(uint16_t port_id, uint16_t queue_id, > + volatile void **wake_addr, uint64_t *expected, uint64_t *mask, > + uint8_t *data_sz); [...] > --- a/lib/librte_ethdev/version.map > +++ b/lib/librte_ethdev/version.map > @@ -244,6 +244,7 @@ EXPERIMENTAL { > rte_flow_get_restore_info; > rte_flow_tunnel_action_decap_release; > rte_flow_tunnel_item_release; > + rte_eth_get_wake_addr; > }; Please sort in alphabetical order.