From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id CE7448086 for ; Fri, 12 Dec 2014 14:00:53 +0100 (CET) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 12 Dec 2014 05:00:52 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,563,1413270000"; d="scan'208";a="636652913" Received: from irsmsx108.ger.corp.intel.com ([163.33.3.3]) by fmsmga001.fm.intel.com with ESMTP; 12 Dec 2014 05:00:51 -0800 Received: from irsmsx109.ger.corp.intel.com ([169.254.13.244]) by IRSMSX108.ger.corp.intel.com ([169.254.11.150]) with mapi id 14.03.0195.001; Fri, 12 Dec 2014 13:00:50 +0000 From: "Carew, Alan" To: Thomas Monjalon , "De Lara Guarch, Pablo" Thread-Topic: [dpdk-dev] [PATCH v4 00/10] VM Power Management Thread-Index: AQHQFZjTjIIFzjRkJ0W3L352fQ+dapyL5wmQ Date: Fri, 12 Dec 2014 13:00:50 +0000 Message-ID: <0E29434AEE0C3A4180987AB476A6F6306D2B6443@IRSMSX109.ger.corp.intel.com> References: <1412003903-9061-1-git-send-email-alan.carew@intel.com> <5470C514.3080307@6wind.com> <548732C9.2020201@redhat.com> <10291528.MoKaz8pbFD@xps13> In-Reply-To: <10291528.MoKaz8pbFD@xps13> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dev@dpdk.org" , Paolo Bonzini , qemu-devel 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 13:00:54 -0000 Hi Paolo, > 2014-12-09 18:35, Paolo Bonzini: > > >>>> Did you make any progress in Qemu/KVM community? > > >>>> We need to be sync'ed up with them to be sure we share the same > goal. > > >>>> I want also to avoid using a solution which doesn't fit with > > >>>> their plan. > > >>>> Remember that we already had this problem with ivshmem which > was > > >>>> planned to be dropped. > > >>> > > >>> Unfortunately, I have not yet received any feedback: > > >>> http://lists.nongnu.org/archive/html/qemu-devel/2014- > 11/msg01103.h > > >>> tml > > >> > > >> Just to add to what Alan said above, this capability does not exist > > >> in qemu at the moment, and based on there having been no feedback > > >> on th qemu mailing list so far, I think it's reasonable to assume > > >> that it will not be implemented in the immediate future. The VM > > >> Power Management feature has also been designed to allow easy > > >> migration to a qemu-based solution when this is supported in > > >> future. Therefore, I'd be in favour of accepting this feature into D= PDK > now. > > >> > > >> It's true that the implementation is a work-around, but there have > > >> been similar cases in DPDK in the past. One recent example that > > >> comes to mind is userspace vhost. The original implementation could > > >> also be considered a work-around, but it met the needs of many in > > >> the community. Now, with support for vhost-user in qemu 2.1, that > > >> implementation is being improved. I'd see VM Power Management > > >> following a similar path when this capability is supported in qemu. > > > > I wonder if this might be papering over a bug in the host cpufreq > > driver. If the guest is not doing much and leaving a lot of idle CPU > > time, the host should scale down the frequency of that CPU. In the > > case of pinned VCPUs this should really "just work". What is the > > problem that is being solved? > > > > Paolo >=20 > Alan, Pablo, please could you explain your logic with VM power > management? >=20 > -- > Thomas The problem is deterministic control of host CPU frequency and the DPDK usa= ge 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 machine= s 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. Thanks, Alan.