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 883D76D45 for ; Fri, 22 Sep 2017 15:03:39 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id EFF4C20BB4; Fri, 22 Sep 2017 09:03:38 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 22 Sep 2017 09:03:38 -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=aJNtb4n5LZ1rAQJ YpVl0jIQ40F+KuGogGjLNxryIOC0=; b=BrE7iV2uHO58/H+Hyl9BKFDypq3bVrj 1Jbe1AE0Ygf97ESTij5Nnuz2clOR9g5SAcHQlIZbIL1rivMfTivn34FtlnIX+hpb 1d+yX08FGa+3r313b00KPFA2arhNcjE/kEgMhmMXuNKk1Dq5FksALbf/Sb8IJ00m QI06FOaROmII= 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=aJNtb4n5LZ1rAQJYpVl0jIQ40F+KuGogGjLNxryIOC0=; b=ifOFsoyZ LEbBbUE0bqHEOnjY3RZI0mCPeK9Jbtdiq/ujmhd/bWbl9mZkcWeAkZd1VKKJYecK EAtiz0/ytKyOvXFhK7JcTc++ximu7LbJB0HK13NiJ9myqHAtAx9hZ6uMBsdzaxso LSMLtT8L+tE/NStRM/W4Farw3i57Uk1goiXLCSl7N8nC8n5L1Jl7y7MTm4ReJ2DV G/WIg2JBJZrPPpKD2jGuQ+LSy127s//jVUjuvdbcUK0GqU8L3L9bb5B9KD3v/ZVa z4eqJ3pCKvfv7yt7PU/2ViIfUf1EWwkksKTlVIAIDZQb5LK0wOUZ4eInakyf3Tz+ AYI+r4uKvUbzmg== X-ME-Sender: X-Sasl-enc: rAZTpixnzqpuSD2lTV5VRoEgMYEB78L8+V5JRwnpdnHV 1506085418 Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 9F5277E7C6; Fri, 22 Sep 2017 09:03:38 -0400 (EDT) From: Thomas Monjalon To: "Hunt, David" Cc: dev@dpdk.org, "Ananyev, Konstantin" Date: Fri, 22 Sep 2017 15:03:37 +0200 Message-ID: <1541048.iMoFMbgTmX@xps> In-Reply-To: References: <1503676941-80981-1-git-send-email-david.hunt@intel.com> <8711422.RO3QJ0tz1I@xps> 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 13:03:39 -0000 22/09/2017 12:28, Hunt, David: > > On 22/9/2017 10:51 AM, Thomas Monjalon wrote: > > 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? > > Hi Thomas, > > We're still working on updates based on Konstantin's feedback above, and > hope to have a new patch set submitted to the mailing list early next > week. This will remove the ethdev layer changes, and uses pre-existing > stats-api. > > In relation to the Turbo patch, they are still independent, but when we > have the next revision of the Policy patch submitted, I'll do a new > version of the Turbo patch so that it can be applied on top of the > policy patch. OK, thanks If the turbo patch is independent, I can push it now?