From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: Xen Platform QoS design discussion Date: Wed, 7 May 2014 10:10:04 +0100 Message-ID: <1399453804.3014.215.camel@kazak.uk.xensource.com> References: <40776A41FC278F40B59438AD47D147A9119F3FEA@SHSMSX104.ccr.corp.intel.com> <1398877340.5166.13.camel@kazak.uk.xensource.com> <40776A41FC278F40B59438AD47D147A9119F42A2@SHSMSX104.ccr.corp.intel.com> <5363804B020000780000E604@mail.emea.novell.com> <40776A41FC278F40B59438AD47D147A9119F4EF4@SHSMSX104.ccr.corp.intel.com> <5363AE54020000780000E7A2@mail.emea.novell.com> <40776A41FC278F40B59438AD47D147A9119FE6BB@SHSMSX104.ccr.corp.intel.com> <5368B418.9000307@citrix.com> <40776A41FC278F40B59438AD47D147A9119FF569@SHSMSX104.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <40776A41FC278F40B59438AD47D147A9119FF569@SHSMSX104.ccr.corp.intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "Xu, Dongxiao" Cc: Andrew Cooper , Jan Beulich , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On Wed, 2014-05-07 at 02:08 +0000, Xu, Dongxiao wrote: > > -----Original Message----- > > From: Andrew Cooper [mailto:andrew.cooper3@citrix.com] > > Sent: Tuesday, May 06, 2014 6:06 PM > > To: Xu, Dongxiao > > Cc: Jan Beulich; Ian Campbell; xen-devel@lists.xen.org > > Subject: Re: Xen Platform QoS design discussion > > > > On 06/05/14 02:40, Xu, Dongxiao wrote: > > >> -----Original Message----- > > >> From: Xu, Dongxiao > > >> Sent: Sunday, May 04, 2014 8:46 AM > > >> To: Jan Beulich > > >> Cc: Andrew Cooper(andrew.cooper3@citrix.com); Ian Campbell; > > >> xen-devel@lists.xen.org > > >> Subject: RE: Xen Platform QoS design discussion > > >> > > >>> -----Original Message----- > > >>> From: Jan Beulich [mailto:JBeulich@suse.com] > > >>> Sent: Friday, May 02, 2014 8:40 PM > > >>> To: Xu, Dongxiao > > >>> Cc: Andrew Cooper(andrew.cooper3@citrix.com); Ian Campbell; > > >>> xen-devel@lists.xen.org > > >>> Subject: RE: Xen Platform QoS design discussion > > >>> > > >>>>>> On 02.05.14 at 14:30, wrote: > > >>>>> -----Original Message----- > > >>>>> From: Jan Beulich [mailto:JBeulich@suse.com] > > >>>>> Sent: Friday, May 02, 2014 5:24 PM > > >>>>> To: Xu, Dongxiao > > >>>>> Cc: Andrew Cooper(andrew.cooper3@citrix.com); Ian Campbell; > > >>>>> xen-devel@lists.xen.org > > >>>>> Subject: RE: Xen Platform QoS design discussion > > >>>>> > > >>>>>>>> On 01.05.14 at 02:56, wrote: > > >>>>>>> From: Ian Campbell [mailto:Ian.Campbell@citrix.com] > > >>>>>>> Have you asked yourself whether this information even needs to be > > >>>>>>> exposed all the way up to libxl? Who are the expected consumers of > > this > > >>>>>>> interface? Are they low-level CLI tools (i.e. like xenpm is) or are you > > >>>>>>> expecting toolstacks to plumb this information all the way up to their > > >>>>>>> GUI or CLI (e.g. xl or virsh)? > > >>>>>> The information returned to libxl users is the cache utilization for a > > >>>>>> certain domain in certain socket, and the main consumers are cloud > > users > > >>>> like > > >>>>>> openstack, etc. Of course, we will also provide an xl command to present > > >>>> such > > >>>>>> information. > > >>>>> To me this doesn't really address the question Ian asked, yet knowing > > >>>>> who's going to be the consumer of the data is also quite relevant for > > >>>>> answering your original question on the method to obtain that data. > > >>>>> Obviously, if the main use of it is per-domain, a domctl would seem like > > >>>>> a suitable approach despite the data being more of sysctl kind. But if > > >>>>> a global view would be more important, that model would seem to make > > >>>>> life needlessly hard for the consumers. In turn, if using a domctl, I tend > > >>>>> to agree that not using shared pages would be preferable; iirc their use > > >>>>> was mainly suggested because of the size of the data. > > >>>> From the discussion with openstack developers, on certain cloud host, all > > >>>> running VM's information (e.g., domain ID) will be stored in a database, and > > >>>> openstack software will use libvirt/XenAPI to query specific domain > > >>>> information. That libvirt/XenAPI API interface basically accepts the domain > > >>>> ID as input parameter and get the domain information, including the > > platform > > >>>> QoS one. > > >>>> > > >>>> Based on above information, I think we'd better design the QoS hypercall > > >>>> per-domain. > > >>> If you think that this is going to be the only (or at least prevalent) > > >>> usage model, that's probably okay then. But I'm a little puzzled that > > >>> all this effort is just for a single, rather specific consumer. I thought > > >>> that if this is so important to Intel there would be wider interested > > >>> audience. > > > Since there is no further comments, I suppose we all agreed on making the > > hypercall per-domain and use data copying mechanism between hypervisor and > > Dom0 tool stack? > > > > > > > Reply previous Ian and Andrew's comments in this mail. > > > No - the onus is very much on you to prove that your API will *not* be > > used in the following way: > > > > every $TIMEPERIOD > > for each domain > > for each type of information > > get-$TYPE-information-for-$DOMAIN > > The "for loop" mentioned here does exist in certain software levels, and there are several options: > 1. For loop in libvirt/openstack layer (likely): > In this case, domctl would be better which returns per-domain's QoS > info. Otherwise it will repeatedly call sysctl hypercall to get the > entire data structure but only returns one domain's info to user > space. > > 2. For loop within libxl API function and returns whole QoS data (unlikely): > If we return such entire PQoS info to Dom0 user space via libxl API, > then this API will be changing once new PQoS feature comes out. I don't see why this is a) any more likely with #2 than #1 or b) why the API can't be designed in such a way as to make it extensible to start with. Please take a look in libxl.h for a bug comment about the mechanisms which we support for extending the API, the most obvious one being that adding a new field to a struct (or case to an enum etc) is OK so long as a suitable #define LIBXL_HAVE_THING is added at the same time.