From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 4483B593E for ; Thu, 16 Oct 2014 17:18:27 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 16 Oct 2014 08:26:10 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,732,1406617200"; d="scan'208";a="590230970" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by orsmga001.jf.intel.com with ESMTP; 16 Oct 2014 08:21:53 -0700 Received: from irsmsx109.ger.corp.intel.com ([169.254.13.253]) by IRSMSX102.ger.corp.intel.com ([169.254.2.200]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 16:21:26 +0100 From: "Carew, Alan" To: "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH v4 00/10] VM Power Management Thread-Index: AQHP5lPntegTcHXUhU2lJ6crRCq8n5wuan2AgAEcXMCAABvQgIABq4tw Date: Thu, 16 Oct 2014 15:21:25 +0000 Message-ID: <0E29434AEE0C3A4180987AB476A6F6306D2811AD@IRSMSX109.ger.corp.intel.com> References: <1412003903-9061-1-git-send-email-alan.carew@intel.com> <3264386.kAdiTFhMft@xps13> <0E29434AEE0C3A4180987AB476A6F6306D28093B@IRSMSX109.ger.corp.intel.com> <3349663.LNtcecTXb3@xps13> In-Reply-To: <3349663.LNtcecTXb3@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.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Thu, 16 Oct 2014 15:18:28 -0000 Hi Thomas, > > However with a DPDK solution it would be possible to re-use the message= bus > > to pass information like device stats, application state, D-state reque= sts > > etc. to the host and allow for management layer(e.g. OpenStack) to make > > informed decisions. >=20 > I think that management informations should be transmitted in a managemen= t > channel. Such solution should exist in OpenStack. Perhaps it does, but this solution is not exclusive to OpenStack and just a= potential use case. >=20 > > Also, the scope of adding power management to qemu/KVM would be huge; > > while the easier path is not always the best and the problem of power > > management in VMs is both a DPDK problem (given that librte_power only > > worked on the host) and a general virtualization problem that would be > > better solved by those with direct knowledge of Qemu/KVM architecture > > and influence on the direction of the Qemu project. >=20 > Being a huge effort is not an argument. I agree completely and was implied by what followed the conjunction. > Please check with Qemu community, they'll welcome it. >=20 > > As it stands, the host backend is simply an example application that ca= n > > be replaced by a VMM or Orchestration layer, by using Virtio-Serial it = has > > obvious leanings to Qemu, but even this could be easily swapped out for > > XenBus, IVSHMEM, IP etc. > > > > If power management is to be eventually supported by Hypervisors direct= ly > > then we could also enable to option to switch to that environment, curr= ently > > the librte_power implementations (VM or Host) can be selected dynamical= ly > > (environment auto-detection) or explicitly via rte_power_set_env(), add= ing > > an arbitrary number of environments is relatively easy. >=20 > Yes, you are adding a new layer to workaround hypervisor lacks. And this = layer > will handle native support when it will exist. But if you implement nativ= e > support now, we don't need this extra layer. Indeed, but we have a solution implemented now and yes it is a workaround, = that is until Hypervisors support such functionality. It is possible that w= hatever solutions for power management present themselves in the future may= require workarounds also, us-vhost is an example of such a workaround intr= oduced to DPDK. >=20 > > I hope this helps to clarify the approach. >=20 > Thanks for your explanation. Thanks for the feedback. >=20 > -- > Thomas Alan.