[Qemu-devel] value of VIRTQUEUE_MAX_SIZE

[Qemu-devel] value of VIRTQUEUE_MAX_SIZE

[Peter Lieven]

Hi,

Just wondering if VIRTQUEUE_MAX_SIZE in include/hw/virtio/virtio.h should not be equal to IOV_MAX instead of the hardcoded 1024?

Thanks,
Peter

Re: [Qemu-devel] value of VIRTQUEUE_MAX_SIZE

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 810 bytes --]

On Fri, Jan 30, 2015 at 10:08:02PM +0100, Peter Lieven wrote:
> Just wondering if VIRTQUEUE_MAX_SIZE in include/hw/virtio/virtio.h should not be equal to IOV_MAX instead of the hardcoded 1024?

The vring queue size is guest-visible to some extent (e.g. vring memory
layout).  Tying it to a constant that is defined by the host operating
system could lead to problems (e.g. live migration between different
hosts).

Anyway, all of the virtio devices have a queue size that is less than or
equal to VIRTQUEUE_MAX_SIZE (and there is an assertion to check this in
virtio_add_queue()).

Guests are supposed to honor the vring queue size, although indirect
descriptors seem to be able to use up to VIRTQUEUE_MAX_SIZE according to
my understanding of QEMU's virtio.c code.

Why would you like to use IOV_MAX?

Stefan

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]

Re: [Qemu-devel] value of VIRTQUEUE_MAX_SIZE

[Peter Lieven]

Am 05.02.2015 um 15:00 schrieb Stefan Hajnoczi:
> On Fri, Jan 30, 2015 at 10:08:02PM +0100, Peter Lieven wrote:
>> Just wondering if VIRTQUEUE_MAX_SIZE in include/hw/virtio/virtio.h should not be equal to IOV_MAX instead of the hardcoded 1024?
> The vring queue size is guest-visible to some extent (e.g. vring memory
> layout).  Tying it to a constant that is defined by the host operating
> system could lead to problems (e.g. live migration between different
> hosts).
>
> Anyway, all of the virtio devices have a queue size that is less than or
> equal to VIRTQUEUE_MAX_SIZE (and there is an assertion to check this in
> virtio_add_queue()).
>
> Guests are supposed to honor the vring queue size, although indirect
> descriptors seem to be able to use up to VIRTQUEUE_MAX_SIZE according to
> my understanding of QEMU's virtio.c code.
>
> Why would you like to use IOV_MAX?

The idea was that IOV_MAX is the limit in case of at least virtio-blk. The host
will not support more than IOV_MAX iovecs passed to a block request.

Peter

Re: [Qemu-devel] value of VIRTQUEUE_MAX_SIZE

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]

On Thu, Feb 05, 2015 at 03:29:17PM +0100, Peter Lieven wrote:
> Am 05.02.2015 um 15:00 schrieb Stefan Hajnoczi:
> >On Fri, Jan 30, 2015 at 10:08:02PM +0100, Peter Lieven wrote:
> >>Just wondering if VIRTQUEUE_MAX_SIZE in include/hw/virtio/virtio.h should not be equal to IOV_MAX instead of the hardcoded 1024?
> >The vring queue size is guest-visible to some extent (e.g. vring memory
> >layout).  Tying it to a constant that is defined by the host operating
> >system could lead to problems (e.g. live migration between different
> >hosts).
> >
> >Anyway, all of the virtio devices have a queue size that is less than or
> >equal to VIRTQUEUE_MAX_SIZE (and there is an assertion to check this in
> >virtio_add_queue()).
> >
> >Guests are supposed to honor the vring queue size, although indirect
> >descriptors seem to be able to use up to VIRTQUEUE_MAX_SIZE according to
> >my understanding of QEMU's virtio.c code.
> >
> >Why would you like to use IOV_MAX?
> 
> The idea was that IOV_MAX is the limit in case of at least virtio-blk. The host
> will not support more than IOV_MAX iovecs passed to a block request.

Is there an issue in practice?

Stefan

[-- Attachment #2: Type: application/pgp-signature, Size: 473 bytes --]

Re: [Qemu-devel] value of VIRTQUEUE_MAX_SIZE

[Peter Lieven]

Am 06.02.2015 um 11:42 schrieb Stefan Hajnoczi:
> On Thu, Feb 05, 2015 at 03:29:17PM +0100, Peter Lieven wrote:
>> Am 05.02.2015 um 15:00 schrieb Stefan Hajnoczi:
>>> On Fri, Jan 30, 2015 at 10:08:02PM +0100, Peter Lieven wrote:
>>>> Just wondering if VIRTQUEUE_MAX_SIZE in include/hw/virtio/virtio.h should not be equal to IOV_MAX instead of the hardcoded 1024?
>>> The vring queue size is guest-visible to some extent (e.g. vring memory
>>> layout).  Tying it to a constant that is defined by the host operating
>>> system could lead to problems (e.g. live migration between different
>>> hosts).
>>>
>>> Anyway, all of the virtio devices have a queue size that is less than or
>>> equal to VIRTQUEUE_MAX_SIZE (and there is an assertion to check this in
>>> virtio_add_queue()).
>>>
>>> Guests are supposed to honor the vring queue size, although indirect
>>> descriptors seem to be able to use up to VIRTQUEUE_MAX_SIZE according to
>>> my understanding of QEMU's virtio.c code.
>>>
>>> Why would you like to use IOV_MAX?
>> The idea was that IOV_MAX is the limit in case of at least virtio-blk. The host
>> will not support more than IOV_MAX iovecs passed to a block request.
> Is there an issue in practice?

If there is no platform where IOV_MAX is less than 1024 then not.

Peter

Re: [Qemu-devel] value of VIRTQUEUE_MAX_SIZE

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 646 bytes --]

On 02/06/2015 03:45 AM, Peter Lieven wrote:

>>> The idea was that IOV_MAX is the limit in case of at least virtio-blk. The host
>>> will not support more than IOV_MAX iovecs passed to a block request.
>> Is there an issue in practice?
> 
> If there is no platform where IOV_MAX is less than 1024 then not.

POSIX allows for a system with IOV_MAX as small as 16. But these days,
systems we care about probably have a much larger value; alas, I don't
know off-hand what actual systems use to say if 1024 is a common minimum.

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]