[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: |
Christian Schoenebeck |
Subject: |
Re: [PATCH v2 0/3] virtio: increase VIRTQUEUE_MAX_SIZE to 32k |
Date: |
Tue, 05 Oct 2021 13:10:56 +0200 |
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, 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 2/3] virtio: increase VIRTQUEUE_MAX_SIZE to 32k, Christian Schoenebeck, 2021/10/04
[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,
Christian Schoenebeck <=
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