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

[Daniel P. Berrange]

On Tue, Aug 21, 2007 at 09:02:45AM +0100, Richard W.M. Jones wrote:
> 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.
> 
> I favour int64_t, because I want 64 bit integers (signed in this case 
> because I want the special -1 value).  C doesn't specify a maximum width 
> for "long long".
> 
> >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 assumed that Xen requests were variable in size ...  That is based on 
> my reading of this code from blkif.h:

Ok, yes I they are variable size. I was mixing up requests vs sectors, the
latter being fixed, the former being variable since they can be made up of
multiple sectors.

> If it is true that requests have a fixed size, then returning bytes 
> _also_ would be good, but I suspect that we should also still return 
> requests as well since (a) it costs virtually nothing to do so, and (b) 
> it might be interesting to find the average size of each request, since 
> lots of small requests are likely to be less efficient than small 
> numbers of large requests.

Yes, we need both. If we can't find actual request sizes for Xen, we should 
make a note and see if its possible add this to future Xen kernel backend
drivers.

> >For hdNNN based disks it seems to be 
> >
> >    ide major number corresponding to disk letter * 256 + minor number
> >    as calculated from partition numbers.
> 
> OK ... I've never seen Xen guests with sdX/hdX devices.  Are they common?

Any HVM guest....    A lot of people do use them in paravirt too, we refuse
to use it in Fedora because the ability to hijack hdN and sdN was disappearing
in paravirt_ops Xen merge. So hopefully not so common in future, but we'll
likely hit them periodically in the wild

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  -=|