From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id E2862A04B5; Tue, 27 Oct 2020 16:52:31 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id BEEB872DF; Tue, 27 Oct 2020 16:52:30 +0100 (CET) Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) by dpdk.org (Postfix) with ESMTP id 94DA472DE for <dev@dpdk.org>; Tue, 27 Oct 2020 16:52:29 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.nyi.internal (Postfix) with ESMTP id 7B19B5801C3; Tue, 27 Oct 2020 11:52:25 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 27 Oct 2020 11:52:25 -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= cGJbuqB1eUmOq8BxVDIicbvKtZTThVGcCanPCjUgK/g=; b=IY9LAw4QZW7gYbbS wO9O7/BYpg/Eo3QkGNY6Z2qImtjeBInOZUvgqgipO653HmayYT1fS4poQSZWrDG2 +TuRxt87eXiXgP0ipB166EmEOTKymR1bRGbzDGpD0JDcQMjsIcNyUVIndYFIq8wz DuAby3vtYshe+Mf2JfgLroG6SRvUZUMGTVHLtP+CUvu7B/aR2HHaCqP06Tr1HHo3 bbG+iUte8Da1DXzHh/ZejI/oJL335ARwOKV0JRqHgJ1XM1ltH0hjPX84ASIPg5fd H/avicUYGxEtQibTPh4HkFKjJjGnu2r90Czc14+/0IBTky/E+XvaMntjxR1gRV+c 5FMnjQ== 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=cGJbuqB1eUmOq8BxVDIicbvKtZTThVGcCanPCjUgK /g=; b=JOUuxqHKBnaTGktH28yH8YYZ/t5lBML0KE0UOaLC+8gc4iU9rerzHWJao lcsi8gtOWX/LhAMsWWP4tKWNN24fZpUrTuT/oV/F1I/giJIREn70/UDdudhRcMJM COueI+DhoyC3Nb41TbeFSvrf0riEj1rh7mOpE+bX4coCAEnW65dSJsHnNzaLvgS1 9zbBu/oFkuotSSUUimJ8NtGNVYhLE19FScHsEZ7PQ5DnkYIDZ/D1LOtKxoMSqiQP 9xZSHq7gUIk9FYJ8iAN23EXewbKGLX8Ri5vEXlWx6wH1yoUUdxp4vYSj5whLP/Bc akekmcvyWimvXZhtBs7nJUi2+3u6A== X-ME-Sender: <xms:NUKYX9gPoTYGW0ijNSs6m7kCzxXV0V9qGNfTc2UzRsisYSGgW7YRqw> <xme:NUKYXyDr5SlpAdMX2PnxjYYMna8xs5kxGC6nWS2-yGlUBGN5I5vU3L4_Cr4YICH2U TIJLossnYx6I3yqXg> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrkeelgdekudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucfkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: <xmx:NUKYX9E0BOF5JkMvGmyVhn5t0dEGLzO26jSejd5bjEOctPvzBZR6rQ> <xmx:NUKYXySvzcnIa4ZXNiXSZt7930pW9Pjo57OroHVwbGgImvjF1kPYRw> <xmx:NUKYX6yuYaFIWP3LDnSxzklTcztKsyJwR--9h1FF87qv9Ml-Xj_w5g> <xmx:OUKYXwfwsD9gayEZwb9aGSiMTPpmR-_2kWHRPX9xNJUeFNA5WkO-yg> Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id B9C3F306467D; Tue, 27 Oct 2020 11:52:18 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: "Liang, Ma" <liang.j.ma@intel.com> 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 <andrew.rybchenko@oktetlabs.ru>, 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: Tue, 27 Oct 2020 16:52:16 +0100 Message-ID: <3195982.LjJ4KgG7bb@thomas> In-Reply-To: <20201027111504.GB15973@sivswdev09.ir.intel.com> References: <1603494392-7181-5-git-send-email-liang.j.ma@intel.com> <2168123.9p5K5TOhLB@thomas> <20201027111504.GB15973@sivswdev09.ir.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 <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> 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".