From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id B660BA0A03; Mon, 18 Jan 2021 17:06:11 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2BB2C140D24; Mon, 18 Jan 2021 17:06:11 +0100 (CET) Received: from wnew2-smtp.messagingengine.com (wnew2-smtp.messagingengine.com [64.147.123.27]) by mails.dpdk.org (Postfix) with ESMTP id D46BF140D1D for ; Mon, 18 Jan 2021 17:06:08 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.west.internal (Postfix) with ESMTP id 2B91D16FB; Mon, 18 Jan 2021 11:06:07 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 18 Jan 2021 11:06:08 -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= IzNzHHb9y4p/CAkvAOdUsN35L7DnxTieczD2KWRf6V4=; b=VUAJWY6ponk+VGDP E3awLfZ+K0bdbae0qIXFwU8UO3JL+yjMh4M1+RZ76A5qRDeZHar8t+RvtnD6tXOa fNDvxWjZhiNOfNAfZE7Hx9NziLbDV6sSZ5mPgdJNFNYc2SYONcmB9MaIPXiu/8av 2Fv00OnjmQ+xpyzRWuzuGSNKQPdGJPPKkB6xZR6Ug3KF8YFS6POoeHu8RMtFXLrk TO0yKExO0kr5xgXx/4SmX/xIcXRxFMPFkgaPJZV9MYPz3n3vRILUOAsAt5iV0Csd Yx4QdXg+QwiYzbN82aIWBAV3uEl59A29UTBrrsDJcf3+YO4IhwtOVDPx10f3imRD HFb4XA== 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=IzNzHHb9y4p/CAkvAOdUsN35L7DnxTieczD2KWRf6 V4=; b=ZqE6uqzFFG6iaf45eQC0l/JavVV3uZVBtyya6xaLz6sF43degFb8Iaq9O l2VLc5/GJI6Pkv7jRgd/YNNxRmTk7xsp2NCOhuCEKTpZ2BWEMW9emIgU/gM+NmZm MbNeKnOlDz3DfdmScx3jW+BUttZI1ItavHch71ytHCFvd/44YJhiJd4J05XTFlqH Ol8yuiOsqZQr0esdrSQeK3uFNycHSlLkhyCurcllku6oXROcPDG7kB3XTBtWr55+ WSeGbMBt8LtGIxyLdRgGZYLrMP+SZJAAxyYnk+g0Q9iny+LirL8BtkzUk8JMOzSv m8wCf2o4t0YEdVLXGaYJJYe3PqnoA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrtdekgdekhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpefgveehtdehjedvgedvgeffleejheeufedtieehffeflefhiedvgeet ffeukeefgfenucffohhmrghinhepughpughkrdhorhhgpdhgihhthhhusgdrtghomhenuc fkphepjeejrddufeegrddvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth 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 ADECC240064; Mon, 18 Jan 2021 11:06:04 -0500 (EST) From: Thomas Monjalon To: David Marchand , "Burakov, Anatoly" , David Hunt , chris.macnamara@intel.com Cc: dev , "Ananyev, Konstantin" , Timothy McDaniel , Bruce Richardson , andrew.rybchenko@oktetlabs.ru, ferruh.yigit@intel.com, ajit.khaparde@broadcom.com, jerinj@marvell.com Date: Mon, 18 Jan 2021 17:06:03 +0100 Message-ID: <6844897.6qp5l1ioRY@thomas> In-Reply-To: <906fafb6-1ed5-7e0d-2357-913be8677fdd@intel.com> References: <906fafb6-1ed5-7e0d-2357-913be8677fdd@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v17 00/11] Add PMD power management X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" 18/01/2021 16:45, Burakov, Anatoly: > On 18-Jan-21 3:24 PM, David Marchand wrote: > > On Thu, Jan 14, 2021 at 3:46 PM Anatoly Burakov > > wrote: > >> > >> This patchset proposes a simple API for Ethernet drivers to cause the > >> CPU to enter a power-optimized state while waiting for packets to > >> arrive. There are multiple proposed mechanisms to achieve said power > >> savings: simple frequency scaling, idle loop, and monitoring the Rx > >> queue for incoming packages. The latter is achieved through cooperation > >> with the NIC driver that will allow us to know address of wake up event, > >> and wait for writes on that address. [...] > >> Why are we putting it into ethdev as opposed to leaving this up to the > >> application? Our customers specifically requested a way to do it with > >> minimal changes to the application code. The current approach allows to > >> just flip a switch and automatically have power savings. The customer laziness is usually a bad justification :) I think we could achieve the same with not too much code on application side. And I'm not sure hiding queue management is sane. Remember this rule: application must remain in control. [...] > > SPDK build is still broken. > > http://mails.dpdk.org/archives/test-report/2021-January/174840.html [...] > > I guess this is because of the added dependency of rte_ethdev to rte_power. > > Afaics, SPDK does not use pkg-config: > > https://github.com/spdk/spdk/blob/master/lib/env_dpdk/env.mk#L53 > > Sooo... this is an SPDK issue then? Because i can't see any way of > fixing the issue on DPDK side. Yes SPDK should not skip pkg-config. But it raises 2 question: - are we breaking ABI compatibility? - is ethdev management expected for librte_power? It makes me wonder whether we should host the few functions mixing librte_ethdev and librte_power somewhere else. The question is where?