On 08/26/2014 08:39 AM, Peter Krempa wrote: > On 08/26/14 13:21, Eric Blake wrote: >> This commit (finally) adds the virDomainBlockCopy API, with the >> intent that it will provide more power to the existing 'virsh >> blockcopy' command. >> >> +/** >> + * VIR_DOMAIN_BLOCK_COPY_BANDWIDTH: >> + * Macro for the virDomainBlockCopy bandwidth tunable: it represents >> + * the maximum bandwidth (in MiB/s) used while getting the copy > > I'll re-iterate here. MiB/s seems a pretty big granularity with a lot of > headroom in the big numbers (2^64 MiB/s networks won't be around for a > while) but not enough options at the small end where we have 1 MiB/s, 2 > MiB/s and nothing between. Oh, good call! > > Regarding your comment virDomainBlockJobSetSpeed specifies default unit > in MiB/s: > > 1) this is a new API so we can choose an arbitrary unit (not that it > would be nice) > > 2) for virDomainBlockJobSetSpeed we can add a flag for the smaller > granularity. > > 3) 2^32 KiB/s is also plenty for today's standard: I'd like to have a > 4TiB/s network/disk drive. > Since we already scale by >>20 in converting to qemu, I think this proposal makes the most sense: add a new flag to all existing virDomainBlock* API that take 'unsigned long bandwidth'; if the flag is present, bandwidth is scaled in bytes, if the flag is absent, bandwidth is scaled in megabytes. For the new virDomainBlockCopy, the parameter is ONLY scaled in bytes (but is a long long everywhere, so it can represent the values that a 32-bit machine can only represent as megabytes - even though no one has an interface with a limit of 2 billion megabytes...) Where things get trickiest is in virsh, where we document that negative values represent effectively unlimited bandwidth - so I have to make sure that I don't cause overflow warnings if a user passes bandwidth -1 (it may be just easier to say that bandwidth 0 is unlimited, and forbid negative numbers). > > You've fixed all the problems with docs I've pointed out and I don't > have any additional comments. > > ACK I'll push shortly, with the change to make the parameter scaled in bytes, and do a followup patch for the new flag to the existing APIs. Getting the new API in before the freeze is the important part, the rest of the series can dribble in after freeze if necessary. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list