[Libvir] [PATCH] Block device and network stats (version 2)

[Daniel Veillard]

On Tue, Aug 21, 2007 at 03:37:41AM +0100, Daniel P. Berrange wrote:
> On Mon, Aug 20, 2007 at 04:31:26PM +0100, Richard W.M. Jones wrote:
> > This patch adds block device and network stats.  The main changes over 
> > the previous version are:
> > 
> > * Remote support.
> > * Change Xen network interface names to have the form "vif<domid>.<n>"[1].
> > 
> > Discussions about the previous version may be found starting here:
> > https://www.redhat.com/archives/libvir-list/2007-August/thread.html#00064
> > 
> > I have left use of stdint.h / int64_t, since it wasn't clear to me what 
> > conclusion people had arrived at.
> 
> Personally I'm for using long long, since its consistent with the other
> existing APIs using 64 bit quantities. They're both standards so there's
> no much of a reason to favour one over the other.

  Actually I have one: we already depend on 'long long' for the libvirt
API while we don't depend yet on stdint.h / int64_t. So I really favour
using unsigned long long there.

> I notice the Xen impl of the block stats only fills in the rd_req and wr_req
> fields, not the rd_bytes and wr_bytes fields. Are requests always fixed at
> 512 bytes in size ? If so, should be just junk those fields and only return
> data in terms of the bytes (other units can be calculated as needed). As a
> point of reference libstatgrab only returns bytes read/written for disks.

  I really prefer to keep the rd_req and wr_req. Maybe Xen isn't smart enough
yet to provide those but other hypervisors may be smarter, and even Xen can
evolve fairly quickly. I would keep the fields and try to initialize as best
as possible depending on the hypervisor.

[...]
> The interface stats look OK to me. The impl which parses /proc/net/dev
> though could be shared with the QEMU driver - only the device name needs
> to be different between them - QEMU will be vnetXXX - we have the actual
> dev name when we create teh TAP device, but don't bother to save it anywhere
> from the looks of things.

  We should probably start to create OS specific modules, I can see how
doing the same on Solaris would be different, this may help protability
a little bit, but it's not urgent IMHO.

 +1 for me, once the interfaces are changed to unsigned long long,

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/