[Libvir] Virtual CPUs functions

[Daniel Veillard]

On Tue, Aug 01, 2006 at 12:45:18PM +0200, Philippe Berthault wrote:
> Hello,
> 
> I'm working on the vpcu patch of Michel Ponceau because he is in 
> vacation for a long time.
> 
> Michel has proposed to add 3 APIs to libvirt:
>  - virDomainSetVcpus
>  - virDomainPinVcpu
>  - virDomainGetVcpus
> 
> I've seen in libvirt mail archives that there was a problem with the 
> virDomainGetVcpus API because the virCpuInfo structure contains a CPU 
> map for only 256 physical CPUs.

  right

> Your proposition to remove cpumap field from virCpuInfo structure and 
> add it as parameter to the virDomainGetVcpus API isn't valid for the 
> following reason:
> 
> The virDomainGetVcpus API fills an array of virCpuInfo structures (one 
> virCpuInfo for one VCPU) but cpumap is for one VCPU, not for all VCPUs 
> at whole.

  The char * cpumap in the latest proposal is not the same a before.

> Your proposition can work only if cpumap is a array of array 
> of characters

  it is an array of bits, interpreted as a grid of 2 dimentions, which
is very common practice in C (an Fortran but it's a bit outside the scope)
I suggested using macros to compute and retrieve the bit indicating if
for a given vCPU the physical CPU is usable or not.

> and if maplen is also an array of integers. This is very 
> complicated solution and not elegant.

  This is the only solution we found based on our criteria, c.f. the 
mail discussion from last month. Accessing the 2 dimentaional array is
a bit harder but not that much. Now when it comes to stylistic issues
with API, sometimes elegant API are just unusable in practice, and
you need to make something more complex to get a real working solution.

> I've also seen that you make a mistake in your proposition because you 
> compute the cpuMapLen from the number of virtual CPUs but the cpumap is 
> related to physical CPUs, not virtual CPUs.
> 
> So, in conclusion, I propose, as you, to remove cpumap field of the 
> virCpuInfo structure but to add an API to retrieve the CPU map of one 
> VCPU. Such API would be:
> 
> int virDomainGetCpus(virDomainPtr domain, unsigned int vcpu, unsigned 
> char *cpumap, int maplen);
> 
> The name is ...GetCpus (not 'Vcpus') because this API get the physical 
> CPU map, not the virtual CPU map.

  And to get the full map you them must iterate over the full set of CPU
which is something we discarded as a possibility when setting the initial
criteria for the API.
  Sorry, no, that won't work. I don't want N call to the library each time
one tries to establish the map needed for example when doing load-balancing.
  Consider the API proposed as a coalesced way to do the N calls required by
your suggestion when running on a N processor machine.

Daniel

-- 
Daniel Veillard      | Red Hat http://redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/