From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id F03EFA0A03; Mon, 18 Jan 2021 18:02:45 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 657F9140D38; Mon, 18 Jan 2021 18:02:45 +0100 (CET) Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by mails.dpdk.org (Postfix) with ESMTP id BBFA4140D37 for <dev@dpdk.org>; Mon, 18 Jan 2021 18:02:43 +0100 (CET) IronPort-SDR: qAaVFnzMvDOJUBRkXQAj4sWfqjVRoOfMcv75IU92SMy2SqEOtaw1km8DKcVCbTDYHhJPvRAuy9 UwM02PQn9t3g== X-IronPort-AV: E=McAfee;i="6000,8403,9868"; a="263633603" X-IronPort-AV: E=Sophos;i="5.79,356,1602572400"; d="scan'208";a="263633603" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jan 2021 09:02:41 -0800 IronPort-SDR: 8ng5l/mFs6emlkwPvdV55/NZa2v6Nt41YfYk/JZqILJdbcDpKTG6nSb+GVupVgev/rF60dLiPc vFUvqIGhPD1w== X-IronPort-AV: E=Sophos;i="5.79,356,1602572400"; d="scan'208";a="383628316" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.213.192.12]) ([10.213.192.12]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Jan 2021 09:02:37 -0800 To: Thomas Monjalon <thomas@monjalon.net>, David Marchand <david.marchand@redhat.com>, David Hunt <david.hunt@intel.com>, chris.macnamara@intel.com Cc: dev <dev@dpdk.org>, "Ananyev, Konstantin" <konstantin.ananyev@intel.com>, Timothy McDaniel <timothy.mcdaniel@intel.com>, Bruce Richardson <bruce.richardson@intel.com>, andrew.rybchenko@oktetlabs.ru, ferruh.yigit@intel.com, ajit.khaparde@broadcom.com, jerinj@marvell.com References: <cover.1610473000.git.anatoly.burakov@intel.com> <CAJFAV8zfrHv8zzo-d22QbYriCi+wVugQBsgZrjtJZschOjivNg@mail.gmail.com> <906fafb6-1ed5-7e0d-2357-913be8677fdd@intel.com> <6844897.6qp5l1ioRY@thomas> From: "Burakov, Anatoly" <anatoly.burakov@intel.com> Message-ID: <3f58e10b-5201-8479-af54-6f5882c5aaa0@intel.com> Date: Mon, 18 Jan 2021 17:02:35 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <6844897.6qp5l1ioRY@thomas> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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 <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> On 18-Jan-21 4:06 PM, Thomas Monjalon wrote: > 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 >>> <anatoly.burakov@intel.com> 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. Yes, we could. Customers could basically take this patch and reimplement it inside their application, and get the same benefits (with also added benefit of having knowledge about their queue/core mapping, and so being able to use the PAUSE or SCALE schemes for more than one queue). However, i still think it's a valid use case - if we can do it that way and have a ready-made power management story, why not? > And I'm not sure hiding queue management is sane. > Remember this rule: application must remain in control. > The application can still be in control by just not using the API and implementing things manually instead. Nothing is being taken away from the ability of application to be 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? Good question. Does including an extra intra-DPDK dependency count as ABI break? I was under impression that we didn't want DPDK to be distributed as individual libraries but rather would like it to be used as a whole, so if internal dependencies between components change, it's not a big deal (unless a third-party build system is used that explicitly specifies dependencies rather than using pkg-config). > - 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? > That could be another possibility. We could put this into a separate library, but IMO it would serve no purpose other than avoiding adding a dependency on *internal* component to librte_power. I'm not sure it's a worthy trade off. -- Thanks, Anatoly