Re: [Libvir] [RFC][PATCH 1/2] Tested NUMA patches for available memory and topology
On Fri, Sep 28, 2007 at 03:45:31PM +0100, Daniel P. Berrange wrote:
On Fri, Sep 28, 2007 at 02:52:51PM +0100, Richard W.M. Jones wrote:
> # src/virsh capabilities
> [...]
> <topology>
> <cells num='1'>
> <cell id='0'>
> <cpus num='4'>
> <cpu id='0'/>
> <cpu id='1'/>
> <cpu id='2'/>
> <cpu id='3'/>
> </cpus>
> </cell>
> </cells>
> </topology>
Do we really need such verbose XML. At the very least the 'num' attribute
is redundant, since you can trivially do count(/topology/cells/cell) or
count(/topology/cells/cell[@id=0]/cpus/cpu) XPath exprs in both cases.
The addition of extra tags every time we have a list is not the style we
have normally used in libvirt. eg, we don't use
<disks>
<disk>
..
</disk>
<disk>
..
</disk>
</disk>
to surround the list of disks in a domain.
I'd prefer to see it looking more like this:
<topology>
<cell id='0'>
<cpu id='0'/>
<cpu id='1'/>
<cpu id='2'/>
<cpu id='3'/>
</cell>
</topology>
I explained why I preferred a more structured approach and the <cells>
construction when I made the proposal
https://www.redhat.com/archives/libvir-list/2007-September/msg00015.html
basically you may hit hierachical topologies which are not flat.
If you want to remove the nums= that mean that from an user perspective if
you use a streaming interface (like SAX) you can't know a priori the size
of the arrays you need to allocate to fill the information. I prefer something
a bit more verbose and a bit more complex to generate but more flexible
in its use. For me <cells> can't go away for structural needs and the count
is for the number of children at that level not at all levels.
We could get rid of <cpus> but
<cpus num='4'>
<cpu id='0'/>
<cpu id='1'/>
<cpu id='3'/>
</cpus>
could allow things like description in hotplug CPUs situations where the
structure/topology does not change but the content does.
Since that part is rather experimental, I prefer to have more structure
than what may looks like sticly necessary right now but have provisions
for the future.
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/