[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On mar, 2013-11-19 at 17:15 +0000, Ian Campbell wrote:
> 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?
We probably can. Situation is as follows:
 - George wanted something like what libxl_set_vcpuaffinity2 does
 - IanJ wanted something like what libxl_set_vcpuaffinity3 does
 - After having introduced them, I actually find uses for both of them,
   and hence I kept them

As per the mechanism used to amend the current API, I don't have a real
preference. Both me and George asked (in a previous thread) what
mechanism we should use, but we did not get much feedback at that time
(not complain, just summing up what has happened).

Right now, I think I just need for someone authoritative enough to
express his preference. You certainly qualify as such, but, if possible,
I'd like to see what the other Ian thinks too, as he's been quite deeply
involved in reviewing this interface.

So, IanJ, any thoughts?

> > 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'll see whether that's true, but yes, I think I can do that.

> > 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.
It (unfortunately) did. :-/

Thanks and Regards,

<<This happens because I choose it to happen!>> (Raistlin Majere)
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.