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 EB21DA04DD; Wed, 28 Oct 2020 13:13:27 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 989BEC9D6; Wed, 28 Oct 2020 13:13:26 +0100 (CET) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id A5FBDC9C0 for ; Wed, 28 Oct 2020 13:13:24 +0100 (CET) IronPort-SDR: 3cPxhx8NpwZ8FjNnFjzZRRqES/O+wvoTpRXcDvhE8rVVx0eyPppGCCf1m1ChWucLn9mRheIwFn 0qKHnl+9DHug== X-IronPort-AV: E=McAfee;i="6000,8403,9787"; a="156022907" X-IronPort-AV: E=Sophos;i="5.77,426,1596524400"; d="scan'208";a="156022907" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Oct 2020 05:13:22 -0700 IronPort-SDR: tDFFITkE+wJAoOygL7URUWRgA7vWi0V6AlOquwHV7J7SY6A/zbSxivxI+i6/TmLWTU6FOjE4Wf VtxQIg9gQaTQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,426,1596524400"; d="scan'208";a="525098358" Received: from irvmail001.ir.intel.com ([163.33.26.43]) by fmsmga006.fm.intel.com with ESMTP; 28 Oct 2020 05:13:19 -0700 Received: from sivswdev09.ir.intel.com (sivswdev09.ir.intel.com [10.237.217.48]) by irvmail001.ir.intel.com (8.14.3/8.13.6/MailSET/Hub) with ESMTP id 09SCDIZ1003406; Wed, 28 Oct 2020 12:13:18 GMT Received: from sivswdev09.ir.intel.com (localhost [127.0.0.1]) by sivswdev09.ir.intel.com with ESMTP id 09SCDIml027542; Wed, 28 Oct 2020 12:13:18 GMT Received: (from lma25@localhost) by sivswdev09.ir.intel.com with LOCAL id 09SCDGlB027536; Wed, 28 Oct 2020 12:13:16 GMT Date: Wed, 28 Oct 2020 12:13:16 +0000 From: "Liang, Ma" To: Ajit Khaparde Cc: dpdk-dev , Ruifeng Wang , Haiyue Wang , Bruce Richardson , "Ananyev, Konstantin" , david.hunt@intel.com, Jerin Jacob , Neil Horman , Thomas Monjalon , timothy.mcdaniel@intel.com, gage.eads@intel.com, Marcin Wojtas , Guy Tzalik , Harman Kalra , John Daley , "Wei Hu (Xavier" , Ziyang Xuan , Matan Azrad , Yong Wang Message-ID: <20201028121316.GA29706@sivswdev09.ir.intel.com> References: <1603494392-7181-1-git-send-email-liang.j.ma@intel.com> <1603810749-22285-1-git-send-email-liang.j.ma@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [PATCH v10 0/9] Add PMD power mgmt 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 27 Oct 13:53, Ajit Khaparde wrote: > On Tue, Oct 27, 2020 at 7:59 AM Liang Ma 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, along with a set of > > generic intrinsics that facilitate that. This is achieved > > through cooperation with the NIC driver that will allow > > us to know address of wake up event, and wait for writes > > on it. > Is the wake event the same as ring status or interrupt status register? the wake event is any change happen to the monitoring address range. can be a ring descriptor(e.g. Done Bits) but not limiti to that. > > So in a way the PMD is passing the address of the next ring descriptor? > So that instead of the PMD polling it, the application peeks at it and > when ready asks the PMD to actually process the packet(s)? NO, after PMD pssing the address, processor will monitoring and wait on the address range(aka, move to a sub-state). any change to the address range caused by other source(another processor, NIC etc) will wake up the processor then start polling again. > > > > > On IA, this is achieved through using UMONITOR/UMWAIT > > instructions. They are used in their raw opcode form > > because there is no widespread compiler support for > > them yet. Still, the API is made generic enough to > > hopefully support other architectures, if they happen > > to implement similar instructions. > > > > To achieve power savings, there is a very simple mechanism > > used: we're counting empty polls, and if a certain threshold > > is reached, we get the address of next RX ring descriptor > > from the NIC driver, arm the monitoring hardware, and > > enter a power-optimized state. We will then wake up when > > either a timeout happens, or a write happens (or generally > > whenever CPU feels like waking up - this is platform- > > specific), and proceed as normal. The empty poll counter is > > reset whenever we actually get packets, so we only go to > > sleep when we know nothing is going on. The mechanism is > > generic which can be used for any write back descriptor. > > > > 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 wit minimal changes to the > > application code. The current approach allows to just > > flip a switch and automatically have power savings. > The application still has to know address of wake up event. Right? > And then it will need the logic to count empty polls and the threshold? > This will be done by application or something else? the empty poll counting is done by the power library callback function which is included in the patch 5. APP has no need change any thing beside the initilization code(call the enable/disable API). please Ref the patch 9 which demostrate how to use it with l3fwd-power. > > > > > - Only 1:1 core to queue mapping is supported, > > meaning that each lcore must at most handle RX on a > > single queue > > - Support 3 type policies. UMWAIT/PAUSE/Frequency_Scale > > - Power management is enabled per-queue > > - The API doesn't extend to other device types > > > > Liang Ma (9): > > eal: add new x86 cpuid support for WAITPKG > > eal: add power management intrinsics > > eal: add intrinsics support check infrastructure > > ethdev: add simple power management API > > power: add PMD power management API and callback > > net/ixgbe: implement power management API > > net/i40e: implement power management API > > net/ice: implement power management API > > examples/l3fwd-power: enable PMD power mgmt > > > > doc/guides/prog_guide/power_man.rst | 48 +++ > > doc/guides/rel_notes/release_20_11.rst | 15 + > > .../sample_app_ug/l3_forward_power_man.rst | 13 + > > drivers/net/i40e/i40e_ethdev.c | 1 + > > drivers/net/i40e/i40e_rxtx.c | 26 ++ > > drivers/net/i40e/i40e_rxtx.h | 2 + > > drivers/net/ice/ice_ethdev.c | 1 + > > drivers/net/ice/ice_rxtx.c | 26 ++ > > drivers/net/ice/ice_rxtx.h | 2 + > > drivers/net/ixgbe/ixgbe_ethdev.c | 1 + > > drivers/net/ixgbe/ixgbe_rxtx.c | 25 ++ > > drivers/net/ixgbe/ixgbe_rxtx.h | 2 + > > examples/l3fwd-power/main.c | 46 ++- > > lib/librte_eal/arm/include/meson.build | 1 + > > .../arm/include/rte_power_intrinsics.h | 60 ++++ > > lib/librte_eal/arm/rte_cpuflags.c | 6 + > > lib/librte_eal/include/generic/rte_cpuflags.h | 26 ++ > > .../include/generic/rte_power_intrinsics.h | 123 +++++++ > > lib/librte_eal/include/meson.build | 1 + > > lib/librte_eal/ppc/include/meson.build | 1 + > > .../ppc/include/rte_power_intrinsics.h | 60 ++++ > > lib/librte_eal/ppc/rte_cpuflags.c | 7 + > > lib/librte_eal/version.map | 1 + > > lib/librte_eal/x86/include/meson.build | 1 + > > lib/librte_eal/x86/include/rte_cpuflags.h | 1 + > > .../x86/include/rte_power_intrinsics.h | 135 ++++++++ > > lib/librte_eal/x86/rte_cpuflags.c | 14 + > > lib/librte_ethdev/rte_ethdev.c | 23 ++ > > lib/librte_ethdev/rte_ethdev.h | 33 ++ > > lib/librte_ethdev/rte_ethdev_driver.h | 28 ++ > > lib/librte_ethdev/version.map | 1 + > > lib/librte_power/meson.build | 5 +- > > lib/librte_power/rte_power_pmd_mgmt.c | 320 ++++++++++++++++++ > > lib/librte_power/rte_power_pmd_mgmt.h | 92 +++++ > > lib/librte_power/version.map | 4 + > > 35 files changed, 1148 insertions(+), 3 deletions(-) > > create mode 100644 lib/librte_eal/arm/include/rte_power_intrinsics.h > > create mode 100644 lib/librte_eal/include/generic/rte_power_intrinsics.h > > create mode 100644 lib/librte_eal/ppc/include/rte_power_intrinsics.h > > create mode 100644 lib/librte_eal/x86/include/rte_power_intrinsics.h > > create mode 100644 lib/librte_power/rte_power_pmd_mgmt.c > > create mode 100644 lib/librte_power/rte_power_pmd_mgmt.h > > > > -- > > 2.17.1 > >