From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (xvm-189-124.dc0.ghst.net [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id A238BA0524; Fri, 8 Jan 2021 17:42:11 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 74A73140E10; Fri, 8 Jan 2021 17:42:11 +0100 (CET) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by mails.dpdk.org (Postfix) with ESMTP id 1024C140E0F for ; Fri, 8 Jan 2021 17:42:09 +0100 (CET) IronPort-SDR: 6eS5xd8FwXC4MkXCxgh3fObR19bDQ+oy8DZrJRrHrMQ6NFewAGkJ8ftdEuHFAsUjEydK7EuWd8 0P8+TF01+zgQ== X-IronPort-AV: E=McAfee;i="6000,8403,9857"; a="165308121" X-IronPort-AV: E=Sophos;i="5.79,331,1602572400"; d="scan'208";a="165308121" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jan 2021 08:42:09 -0800 IronPort-SDR: taRJJ+HRz5aJfX8CNJUKfeiOEiu6VnDtmCp/0sksnON+u0vweIlXhchFOapKSYknbO8t751fTl BM7fvDlRY3yQ== X-IronPort-AV: E=Sophos;i="5.79,331,1602572400"; d="scan'208";a="422997458" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.213.237.8]) ([10.213.237.8]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Jan 2021 08:42:05 -0800 To: David Marchand Cc: dev , Thomas Monjalon , "Ananyev, Konstantin" , Gage Eads , Timothy McDaniel , David Hunt , Bruce Richardson , chris.macnamara@intel.com, Ray Kinsella , "Yigit, Ferruh" References: <1604315406-27669-1-git-send-email-liang.j.ma@intel.com> From: "Burakov, Anatoly" Message-ID: Date: Fri, 8 Jan 2021 16:42:03 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v12 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" On 17-Dec-20 4:12 PM, David Marchand wrote: > On Thu, Dec 17, 2020 at 3:06 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. 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. >> >> 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. >> >> This patchset also introduces a few changes into existing power >> management-related intrinsics, namely to provide a native way of waking >> up a sleeping core without application being responsible for it, as well >> as general robustness improvements. There's quite a bit of locking going >> on, but these locks are per-thread and very little (if any) contention >> is expected, so the performance impact shouldn't be that bad (and in any >> case the locking happens when we're about to sleep anyway, not on a >> hotpath). >> >> 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. >> >> - 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. Monitor/Pause/Frequency Scaling >> - Power management is enabled per-queue >> - The API doesn't extend to other device types > > Fyi, ovsrobot Travis being KO, you probably missed that GHA CI caught this: > https://github.com/ovsrobot/dpdk/runs/1571056574?check_suite_focus=true#step:13:16082 > > We will have to put an exception on driver only ABI. > > Why does aarch64 build fail there? The functions in question are in the version map file, but the build complains that they aren't. -- Thanks, Anatoly