[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 0/3] virtio: increase VIRTQUEUE_MAX_SIZE to 32k
From: |
Michael S. Tsirkin |
Subject: |
Re: [PATCH v2 0/3] virtio: increase VIRTQUEUE_MAX_SIZE to 32k |
Date: |
Tue, 5 Oct 2021 07:19:43 -0400 |
On Tue, Oct 05, 2021 at 01:10:56PM +0200, Christian Schoenebeck wrote:
> On Dienstag, 5. Oktober 2021 09:38:53 CEST David Hildenbrand wrote:
> > On 04.10.21 21:38, Christian Schoenebeck wrote:
> > > At the moment the maximum transfer size with virtio is limited to 4M
> > > (1024 * PAGE_SIZE). This series raises this limit to its maximum
> > > theoretical possible transfer size of 128M (32k pages) according to the
> > > virtio specs:
> > >
> > > https://docs.oasis-open.org/virtio/virtio/v1.1/cs01/virtio-v1.1-cs01.html#
> > > x1-240006
> > I'm missing the "why do we care". Can you comment on that?
>
> Primary motivation is the possibility of improved performance, e.g. in case
> of
> 9pfs, people can raise the maximum transfer size with the Linux 9p client's
> 'msize' option on guest side (and only on guest side actually). If guest
> performs large chunk I/O, e.g. consider something "useful" like this one on
> guest side:
>
> time cat large_file_on_9pfs.dat > /dev/null
>
> Then there is a noticable performance increase with higher transfer size
> values. That performance gain is continuous with rising transfer size values,
> but the performance increase obviously shrinks with rising transfer sizes as
> well, as with similar concepts in general like cache sizes, etc.
>
> Then a secondary motivation is described in reason (2) of patch 2: if the
> transfer size is configurable on guest side (like it is the case with the
> 9pfs
> 'msize' option), then there is the unpleasant side effect that the current
> virtio limit of 4M is invisible to guest; as this value of 4M is simply an
> arbitrarily limit set on QEMU side in the past (probably just implementation
> motivated on QEMU side at that point), i.e. it is not a limit specified by
> the
> virtio protocol,
According to the spec it's specified, sure enough: vq size limits the
size of indirect descriptors too.
However, ever since commit 44ed8089e991a60d614abe0ee4b9057a28b364e4 we
do not enforce it in the driver ...
> nor is this limit be made aware to guest via virtio protocol
> at all. The consequence with 9pfs would be if user tries to go higher than
> 4M,
> then the system would simply hang with this QEMU error:
>
> virtio: too many write descriptors in indirect table
>
> Now whether this is an issue or not for individual virtio users, depends on
> whether the individual virtio user already had its own limitation <= 4M
> enforced on its side.
>
> Best regards,
> Christian Schoenebeck
>
- Re: [PATCH v2 1/3] virtio: turn VIRTQUEUE_MAX_SIZE into a variable, (continued)
[PATCH v2 3/3] virtio-9p-device: switch to 32k max. transfer size, Christian Schoenebeck, 2021/10/04
Re: [PATCH v2 0/3] virtio: increase VIRTQUEUE_MAX_SIZE to 32k, David Hildenbrand, 2021/10/05
Re: [PATCH v2 0/3] virtio: increase VIRTQUEUE_MAX_SIZE to 32k, Stefan Hajnoczi, 2021/10/07
- Re: [PATCH v2 0/3] virtio: increase VIRTQUEUE_MAX_SIZE to 32k, Christian Schoenebeck, 2021/10/07
- Re: [PATCH v2 0/3] virtio: increase VIRTQUEUE_MAX_SIZE to 32k, Stefan Hajnoczi, 2021/10/07
- Re: [PATCH v2 0/3] virtio: increase VIRTQUEUE_MAX_SIZE to 32k, Greg Kurz, 2021/10/08
- Re: [PATCH v2 0/3] virtio: increase VIRTQUEUE_MAX_SIZE to 32k, Christian Schoenebeck, 2021/10/08
- Re: [PATCH v2 0/3] virtio: increase VIRTQUEUE_MAX_SIZE to 32k, Christian Schoenebeck, 2021/10/08
- Re: [PATCH v2 0/3] virtio: increase VIRTQUEUE_MAX_SIZE to 32k, Christian Schoenebeck, 2021/10/21
- Re: [PATCH v2 0/3] virtio: increase VIRTQUEUE_MAX_SIZE to 32k, Stefan Hajnoczi, 2021/10/25
- Re: [PATCH v2 0/3] virtio: increase VIRTQUEUE_MAX_SIZE to 32k, Christian Schoenebeck, 2021/10/25