Re: [libvirt] [RFC] New API to retrieve node CPU map

On 10/10/2012 09:18 AM, Viktor Mihajlovski wrote: > Hi, > > in order to use the APIs listed below it is necessary for a client to > know the maximum number of node CPUs which is passed via the maplen > argument. > > virDomainGetEmulatorPinInfo > virDomainGetVcpuPinInfo > virDomainGetVcpus > virDomainPinEmulator > virDomainPinVcpu > virDomainPinVcpuFlags > > The current approach uses virNodeGetInfo to determine the maximum CPU > number. This can lead to incorrect results if not all node CPUs are > online. The maximum CPU number should always be the number of CPUs > present on the host, regardless of their online/offline state. > > This is not a display problem only, because it is also not possible to > explicitly pin the virtual CPU to host CPUs 0 and 2, due to the > truncated CPU mask. Indeed, offline host cpus introduce lots of oddities. Your idea of a new API makes sense, although there's still some details to work out. > > PROPOSAL: > > To help solve the issue above I suggest two new public API functions: > > int > virNodeGetCpuNum(virConnectPtr conn); > > returning the number of present CPUs on the host or -1 upon failure > and > > int > virNodeGetCpuMap(virConnectPtr conn, unsigned char * cpumap, int maplen); Lately, we have been favoring APIs that auto-allocate, instead of making the user call two separate APIs and risk a race where the answer from the first call is no longer matching reality during the second call. That is, if I hot[un]plug a CPU in between the two proposed API calls, will my maplen of the second call as learned from the first call still be accurate? And why should I have to call two functions? I think it might be better to write: int virNodeGetCpuMap(virConnectPtr conn, unsigned char **cpumap); where *cpumap will be malloc'd by libvirt and the return value be the maplen (also allow cpumap==NULL on entry to just query the map len without also allocating). Then the result is -1/maplen instead of -1/0 for failure/success. > > returning the number of present CPUs or -1 on failure and storing a bit > map of real CPUs as described in virDomainPinVcpu in cpumap. The bits in > the bit map are set to 1 for online CPUs and set to 0 for offline CPUs. > > Implementation is facilitated by the function nodeGetCPUmap in nodeinfo.c. > > Clients can use virNodeGetCpuNum to properly determine the maximum > number of node CPUs and the online/offline information. > > Thanks for your comments. Are you interested in writing patches to implement this new API, if others agree with my alternate single-API signature?