Re: [Libvir] Extending libvirt to probe NUMA topology
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. 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? -- Elizabeth Kon (Beth) IBM Linux Technology Center Open Hypervisor Team email: eak@us.ibm.com
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.
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. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
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 -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Daniel Veillard wrote:
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
That sounds fine. Thanks for the offer, Daniel! -- Elizabeth Kon (Beth) IBM Linux Technology Center Open Hypervisor Team email: eak@us.ibm.com
participants (3)
-
beth kon -
Daniel P. Berrange -
Daniel Veillard