From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 0F5497CCD for ; Fri, 22 Sep 2017 11:51:03 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6E6A8216C8; Fri, 22 Sep 2017 05:51:03 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 22 Sep 2017 05:51:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=aC63SKEnKXtzMZG PG1vlwG36DD8VdP/YtjBqIdm/VhE=; b=coIag790WfL8a0ps3DMkQlNywGNJQZ2 LS3rZW71gHAVZDZdTJCt4xlX8+AuoeccynJ71SxQjb3lHORigMaZRSEBZcs5sHi0 Yh7iOUmyCtPyqH/66LSkHBH6rQ3x0TySstclRnhDRQQkm+/G/F2xhFkxgrempJly Qv3qQTYXUlT0= 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-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=aC63SKEnKXtzMZGPG1vlwG36DD8VdP/YtjBqIdm/VhE=; b=HCuEyRKQ jo01BaPBsYKN3CyppFQVSAggDzgcOdOI9SNXmRtIrJQ+rD3A2NnhJzepms4j67AO /fB9K3SS28YxyqAAR7U8v+U3Qn0kr+R0hcgcZoyCzvb8oMmrx7Jx+94HymfHn4xE iGVxkGbnxKXg8S5eVSnUhqI+iPB7hLDxLtr98jPsB6OMnfv/Ziee87fM4NBb6HlM wIM2yTYAavMtmj/QS7Kq+zMk75kc5SnQI4IxrMoDa8AkUk6xiPyTT5A/b/qz3iou pG3PcUH27ky4DpzS5kosi4ilda6XygE6f7vUj3iUMeZMHGnGepdwDMpJKH2Yq9A8 jhFT6vfMw6g2sg== X-ME-Sender: X-Sasl-enc: QdBbqz4brF23Aged1avDuHJq8oG86Mjo2jKNG9Cq1f6+ 1506073863 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 105407E7C6; Fri, 22 Sep 2017 05:51:03 -0400 (EDT) From: Thomas Monjalon To: "Hunt, David" Cc: dev@dpdk.org, "Ananyev, Konstantin" Date: Fri, 22 Sep 2017 11:51:02 +0200 Message-ID: <8711422.RO3QJ0tz1I@xps> In-Reply-To: <2601191342CEEE43887BDE71AB9772584F23D987@IRSMSX103.ger.corp.intel.com> References: <1503676941-80981-1-git-send-email-david.hunt@intel.com> <2601191342CEEE43887BDE71AB9772584F23D987@IRSMSX103.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v1 0/10] Policy Based Power Control for Guest 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: , X-List-Received-Date: Fri, 22 Sep 2017 09:51:04 -0000 29/08/2017 15:03, Ananyev, Konstantin: > > Hi Dave, > > > This patchset adds the facility for a guest VM to send a policy down to > > the host that will allow the host to scale up/down cpu frequencies > > depending on the policy criteria independently of the DPDK app running in > > the guest. This differs from the previous vm_power implementation where > > individual scale up/down requests were send from the guest to the host via > > virtio-serial. > > > > It's a modification of the vm_power_manager app that runs in the host, and > > the guest_vm_power_app example app that runs in the guest. This allows the > > guest to send down a policy to the host via virtio-serial, which then allows > > the host to scale up/down based on the criteria in the policy, resulting in > > quicker scale up/down than individual requests coming from the guest. > > It also means that the DPDK application running in the guest does not need > > to be modified in any way, it is unaware that it's cores are being scaled > > up/down, reducing the effort in implementing a power-aware infrastructure. > > > > The usage model is as follows: > > 1. Set up the VF's and assign to the guest in the usual way. > > 2. run vm_power_manager on the host, creating a channel to the guest. > > 3. Start the guest_vm_power_mgr app on the guest, which establishes > > a virtio-serial channel to the host. > > 4. Send down the profile for the guest using the "send_profile now" command. > > There is an example profile hard-coded into guest_vm_power_mgr. > > 5. Stop the guest_vm_power_mgr and run your normal power-unaware application. > > 6. Send traffic into the VFs at varying traffic rates. > > Observe the frequency change on the host (turbostat -i 1) > > > > The sequence of code changes are as follows: > > > > Firstly, two new API calls are added to the ethdev layer > > 1. One to convert a VF id to a PF id. In the patchset > > this id is a MAC address. This is needed so that the host can map the VFs > > in the profile to PF so in can monitor the traffic on the relevant PF at the > > host level. > > 2. The other function is to read the low-level traffic throughput on the NIC. > > Currently this API reads a NIC register for speed, but we are looking at > > using a more generic way to get these stats, suggestions welcome. > > Why do you need a server (host) to collect RX/TX statistics for VM? > Such method seems to have a lot of limitations: > - no clear method to identify to which VM that VF belongs. > - rely on HW ability to provide such statistics for PF > (limited HW support). > - wouldn't work if PF is not controlled by the same DPDK app. > Why not to make it client(VM) responsibility to collect that statistics and > periodically send it to the server? > Then server just will have to process that data and make decision. Any progress Dave? You have another series "turbo boost API". Does it depends on this one?