Re: [Libvir] Extending libvirt to probe NUMA topology

On Tue, Sep 11, 2007 at 03:08:46AM +0100, Daniel P. Berrange wrote: >On Mon, Sep 10, 2007 at 09:52:46PM -0400, beth kon wrote: > > >>Daniel, >> >>I'm taking a stab at this work and want to be sure I'm taking the right >>approach. I'm new to xen and even newer to libvirt, so have a bit of a >>learning curve. >> >> I suggest the following: I make all the libvirt specific infrastructure work to plug the new calls which is where I will be the most efficient, and I let you plug code to talk to Xen which is where you will be more up to date and able to test, okay ? >>For the topology information, I assume that this will be a call through >>xend, similar to xenDaemonNodeGetInfo. It would seem natural to somehow >>extend the xenDaemonNodeGetInfo with this additional information except >>that you suggested having the output in XML. Can you explain why you >>chose XML? >> >> >We have to maintain 100% ABI & API compatability against older releases >of libvirt. This means that once we add a function, struct or other >definition in the header files it cannot ever be changed again. So this >means we can't change the virNodeInfo struct to add NUMA info. > >For this reason we tend to keep struct's just for use in APIs where the >performance is critical, or data set is unlikely to ever change. So far >we only use structs for virDomainInfo, virNodeInfo, virSchedParam and >virVcpuInfo at this time. For more descriptive data we format information >into an XML document. This makes it very easy to add new XML elements and >attributes to represent new data items. The same compatability rules apply >to XML though - once we add an attribute or element it can never be removed >from the spec. Currently we think putting the NUMA info into XML is the >best approach since it is not performance critical. > > >There are two ways to implement it with Xen - either talk to XenD and >extract the topology there, or make direct hypercalls. For now it is >probably easiest to talk to XenD, since this isn't performance critical. > > Agreed, we could use the hypervisor calls but that means extending that module which is already a bit painful for all the backward compatibility workaround. Xend access should be simpler, at least in a first implementation. I will try to come later today with a first patch defining the framework and leaving functions to fill for the new calls in the xend_internal.c backend. Daniel