From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: Xen Platform QoS design discussion Date: Wed, 30 Apr 2014 18:02:20 +0100 Message-ID: <1398877340.5166.13.camel@kazak.uk.xensource.com> References: <40776A41FC278F40B59438AD47D147A9119F3FEA@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: <40776A41FC278F40B59438AD47D147A9119F3FEA@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 (andrew.cooper3@citrix.com)" , "Jan Beulich (JBeulich@suse.com)" , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org 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. 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). 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)? Ian.