Re: [Xen-devel] [PATCH v3 11/14] libxl: get and set soft affinity

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Tue, 2013-11-19 at 17:09 +0100, Dario Faggioli wrote:
> On mar, 2013-11-19 at 15:41 +0000, George Dunlap wrote:
> > On 11/18/2013 06:18 PM, Dario Faggioli wrote:
> > > Make space for two new cpumap-s, one in vcpu_info (for getting
> > > soft affinity) and build_info (for setting it). Provide two
> > > new API calls:
> > >
> > >   * libxl_set_vcpuaffinity2, taking a cpumap and setting either
> > >     hard, soft or both affinity to it, depending on 'flags';
> > >   * libxl_set_vcpuaffinity3, taking two cpumap, one for hard
> > >     and one for soft affinity.

I must confess that in the end I really dislike these foo, fooN, fooM
style functions. Can we not use LIBXL_APIVERSION here to allow us to
uprev the API?

> > >
> > > The bheavior of the existing libxl_set_vcpuaffinity is left
> > > unchanged, i.e., it only set hard affinity.
> > >
> > > Getting soft affinity happens indirectly, via `xl vcpu-list'
> > > (as it is already for hard affinity).
> > >
> > > The new calls include logic to check whether the affinity which
> > > will be used by Xen to schedule the vCPU(s) does actually match
> > > with the cpumap provided. In fact, we want to allow every possible
> > > combination of hard and soft affinities to be set, but we warn
> > > the user upon particularly weird combinations (e.g., hard and
> > > soft being disjoint sets of pCPUs).
> > >
> > > Also, this is the first change breaking the libxl ABI, so it
> > > bumps the MAJOR.
> > >
> > > Signed-off-by: Dario Faggioli <dario.faggioli@xxxxxxxxxx>
> > 
> > The interface is fine with me (I would probably just have 2 and not 3, 
> > but I'm OK with both).  Just a few minor comments:
> > 
> the '3' variant (tries to) accomplish what IanJ explicitly asked: having
> a way to set both hard and soft affinity at the same time, and each with
> its own value, and only checking for consistency at the very end.

Can this not be accomplished by a single function which accepts one or
zero of the bitmasks being NULL?
 
> I also wasn't sure whether that would have been actually useful but, I
> have to admit, it turned out it is, as it can be seen in the following
> patches, when the interface is used to (re)implement both the existing
> and the new xl commands and command variants.

So did ...2 turn out not to be useful? Lets not provide both in that
case.

> 
> Let's see what IanJ thinks, I guess. :-)
> 

Ian.C.



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