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(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/