From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by dpdk.org (Postfix) with ESMTP id BCF168099 for ; Fri, 12 Dec 2014 17:10:34 +0100 (CET) Received: by mail-wi0-f181.google.com with SMTP id r20so3031286wiv.14 for ; Fri, 12 Dec 2014 08:10:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=OkrV9XzsSsLTeMpDnH3HAyq+IH2zLqIzZ1MxcfQQbu0=; b=ix/MKHyRq65tt8pWIwRCTFBlONkOEBDiglqUCsyctE/ktqRiGWl9TqtdaQmhUPlH4Y /znRvSEBDIudb0rNunnmFfL7sRK4Ch12m6m8Fg3ZgmMSIaJk5KzlQ1mYWOkVdYNjzxO+ E0sRl0hwffdcSM2d3N1TIqatMUFgnytYELSS9Y6Lqkp2P5fKIz6I2ayc+pAEhgHcN9hE DhdgOA39oVUmYYzDLGe9NP4PvWdStmx8e5gsFCrqRJzKP5aJCMhMleJhj8p8XezxXiYs jEAt8r9VoKNqRiUh5ywry44Z+JrB9IDQnRY90dRHQOs0lWUJfcZEnumi8Sm14bAXOvqO 3MJw== X-Gm-Message-State: ALoCoQnpSx1Sim6tHcakRp/FABmyKG8pjHOhDEmxMRcPoaHs0aK//DVjn1seEYfHcHTD/R9E30d1 X-Received: by 10.180.106.33 with SMTP id gr1mr9144816wib.82.1418400634576; Fri, 12 Dec 2014 08:10:34 -0800 (PST) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id rx8sm2344481wjb.30.2014.12.12.08.10.33 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Dec 2014 08:10:33 -0800 (PST) From: Thomas Monjalon To: Paolo Bonzini Date: Fri, 12 Dec 2014 17:10:08 +0100 Message-ID: <6597811.ARdDfzU0XI@xps13> Organization: 6WIND User-Agent: KMail/4.14.3 (Linux/3.17.4-1-ARCH; KDE/4.14.3; x86_64; ; ) In-Reply-To: <548B00B3.8040201@redhat.com> References: <1412003903-9061-1-git-send-email-alan.carew@intel.com> <0E29434AEE0C3A4180987AB476A6F6306D2B6443@IRSMSX109.ger.corp.intel.com> <548B00B3.8040201@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org, qemu-devel@nongnu.org Subject: Re: [dpdk-dev] [PATCH v4 00/10] VM Power Management X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 16:10:35 -0000 2014-12-12 15:50, Paolo Bonzini: > On 12/12/2014 14:00, Carew, Alan wrote: > > The problem is deterministic control of host CPU frequency and the DPDK usage > > model. > > A hands-off power governor will scale based on workload, whether this is a host > > application or VM, so no problems or bug there. > > > > Where this solution fits is where an application wants to control its own > > power policy, for example l3fwd_power uses librte_power library to change > > frequency via apci_cpufreq based on application heuristics rather than > > relying on an inbuilt policy for example ondemand or performance. > > > > This ability has existed in DPDK for host usage for some time and VM power > > management allows this use case to be extended to cater for virtual machines > > by re-using the librte_power interface to encapsulate the VM->Host > > comms and provide an example means of managing such communications. > > > > I hope this clears it up a bit. > > Ok, this looks specific enough that an out-of-band solution within DPDK > sounds like the best approach. It seems unnecessary to involve the > hypervisor (neither KVM nor QEMU). Paolo, I don't understand why you don't imagine controlling frequency scaling of a pinned vCPU transparently? In my understanding, we currently cannot control frequency scaling without knowing wether we are in a VM or not. -- Thomas