[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] virtio-rng: correct the default limit rate

From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH] virtio-rng: correct the default limit rate
Date: Tue, 26 Nov 2013 07:32:37 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0

[adding libvirt]

On 11/26/2013 06:58 AM, Paolo Bonzini wrote:
> Il 26/11/2013 14:43, Amos Kong ha scritto:
>> /* Set a default rate limit of 2^47 bytes per minute or roughly 2TB/s.  If
>>  * you have an entropy source capable of generating more entropy than this
>>  * and you can pass it through via virtio-rng, then hats off to you.  Until
>>  * then, this is unlimited for all practical purposes.
>>  */
>> But the current rate is (INT64_MAX) bytes per (1 << 16) ms, it's 128,000 TB/s
> You are changing:
> * max-bytes from 2^63 to 2^47
> * period from 65536 to 60000
> For a user, changing only period would have no effect, the limit rate
> would remain effectively infinite.  Changing max-bytes would give a 7%
> higher rate after your patch.
> Not a big deal, and max-bytes is easier to explain after your patch
> (bytes/minute) than before (bytes/65536ms).
> Reviewed-by: Paolo Bonzini <address@hidden>

Hmm.  Libvirt is already converting a user's rate of bytes/period into
the qemu parameters, defaulting to 1 second as its default period.  Am I
correct that as long as libvirt specified both rate AND period, then
this change has no impact (and that the 7% change occurs if you specify
period while leaving max-bytes alone)?  Or is this an ABI change where
libvirt will have to be taught to be smart enough to know whether it is
old qemu or new qemu to adjust how libvirt does its calculations when
converting the user's rate into qemu terms?

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]