Re: Xen Platform QoS design discussion

From: "Xu, Dongxiao" <dongxiao.xu@intel.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "Andrew Cooper (andrew.cooper3@citrix.com)"
	<andrew.cooper3@citrix.com>,
	"Jan Beulich (JBeulich@suse.com)" <JBeulich@suse.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: Xen Platform QoS design discussion
Date: Thu, 1 May 2014 00:56:29 +0000	[thread overview]
Message-ID: <40776A41FC278F40B59438AD47D147A9119F42A2@SHSMSX104.ccr.corp.intel.com> (raw)
In-Reply-To: <1398877340.5166.13.camel@kazak.uk.xensource.com>

> -----Original Message-----
> From: Ian Campbell [mailto:Ian.Campbell@citrix.com]
> Sent: Thursday, May 01, 2014 1:02 AM
> To: Xu, Dongxiao
> Cc: Jan Beulich (JBeulich@suse.com); Andrew Cooper
> (andrew.cooper3@citrix.com); xen-devel@lists.xen.org
> Subject: Re: Xen Platform QoS design discussion
> 
> On Wed, 2014-04-30 at 16:47 +0000, Xu, Dongxiao wrote:
> > domain related QoS data. Here I propose to use the domctl style
> > hypercall to get QoS data for specific domain. This has the advantage
> > of simplifying the libxl QoS APIs for user-space developers, and also
> > make the QoS memory allocation in Xen much easier.
> 
> Note that the libxl QoS API need not have any particular resemblance to
> the underlying hypercall API, it is perfectly reasonable for libxl (or
> libxc even) to massage the data provided by the raw hypercall (or
> several hypercalls) into something nicer for end user consumption.

Yes, I understand.
If use sysctl to get per-domain QoS info, Xen still needs to provide the entire QoS data for user, and libxl QoS API may extract the per-domain data from it. However this is not high efficient.
While using domctl, Xen provides the exact info that needed by Dom0 toolstack.

> 
> The important thing about any libxl level interface is that the library
> API cannot change once it has been introduced, so thought needs to be
> given to extensibility and future proofing. The API should also be
> structured (so no binary blobs, or arrays of numbers which need special
> knowledge to interpret etc).

Agree.
Previously we are returning an 2-dimention array of nr_rmids * nr_sockets number of data back to Dom0 toolstack. Since the size may already very big, so we structure the data in binary blob to save memory space. If using domctl, then the data is only 1-dimention and much less, and we can use structured data to present to libxl users.

> 
> 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.

Thanks,
Dongxiao

> 
> Ian.