Re: [Xen-devel] Xen Platform QoS design discussion

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Sun, 2014-05-04 at 02:34 +0000, Xu, Dongxiao wrote:
> > -----Original Message-----
> > From: Andrew Cooper [mailto:andrew.cooper3@xxxxxxxxxx]
> > Sent: Friday, May 02, 2014 8:51 PM
> > To: Xu, Dongxiao
> > Cc: Jan Beulich; Ian Campbell; xen-devel@xxxxxxxxxxxxx
> > Subject: Re: Xen Platform QoS design discussion
> > 
> > On 02/05/14 13:30, Xu, Dongxiao wrote:
> > >> -----Original Message-----
> > >> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> > >> Sent: Friday, May 02, 2014 5:24 PM
> > >> To: Xu, Dongxiao
> > >> Cc: Andrew Cooper(andrew.cooper3@xxxxxxxxxx); Ian Campbell;
> > >> xen-devel@xxxxxxxxxxxxx
> > >> Subject: RE: Xen Platform QoS design discussion
> > >>
> > >>>>> On 01.05.14 at 02:56, <dongxiao.xu@xxxxxxxxx> wrote:
> > >>>> From: Ian Campbell [mailto:Ian.Campbell@xxxxxxxxxx]
> > >>>> 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.
> > 
> > The design of the hypercall has nothing to do with the design of the
> > libxl/XenAPI interface.
> 
> If use the share mechanism between Xen and Dom0 user space, plus
> explicitly listing all the available CQM features as you proposed (see
> below structure cited from previous mail), then the ABI between Xen
> and Dom0 user space may need to be changing every time when a new QoS
> feature is introduced, which breaks the compatibility to some
> extent. :(

This is generally acceptable for a domctl, although if it can be defined
to avoid it even better.

This isn't acceptable for the libxl layer interface though, there API
compatibility is required.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel