Re: [Libvir] [RFC][PATCH 1/2] Tested NUMA patches for available memory and topology

28 Sep 2007

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