All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Christian Schoenebeck <qemu_oss@crudebyte.com>
Cc: "Kevin Wolf" <kwolf@redhat.com>,
	"Laurent Vivier" <lvivier@redhat.com>,
	qemu-block@nongnu.org, "David Hildenbrand" <david@redhat.com>,
	"Jason Wang" <jasowang@redhat.com>, "Amit Shah" <amit@kernel.org>,
	qemu-devel@nongnu.org, virtio-fs@redhat.com,
	"Eric Auger" <eric.auger@redhat.com>,
	"Hanna Reitz" <hreitz@redhat.com>,
	"Gonglei (Arei)" <arei.gonglei@huawei.com>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Fam Zheng" <fam@euphon.net>,
	"Raphael Norwitz" <raphael.norwitz@nutanix.com>
Subject: Re: [Virtio-fs] [PATCH v2 0/3] virtio: increase VIRTQUEUE_MAX_SIZE to 32k
Date: Tue, 5 Oct 2021 07:19:43 -0400	[thread overview]
Message-ID: <20211005071300-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <3198289.vhBqKWSW6W@silver>

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
> 


WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Christian Schoenebeck <qemu_oss@crudebyte.com>
Cc: "Kevin Wolf" <kwolf@redhat.com>,
	"Laurent Vivier" <lvivier@redhat.com>,
	qemu-block@nongnu.org, "David Hildenbrand" <david@redhat.com>,
	"Jason Wang" <jasowang@redhat.com>, "Amit Shah" <amit@kernel.org>,
	qemu-devel@nongnu.org, "Greg Kurz" <groug@kaod.org>,
	virtio-fs@redhat.com, "Eric Auger" <eric.auger@redhat.com>,
	"Hanna Reitz" <hreitz@redhat.com>,
	"Gonglei (Arei)" <arei.gonglei@huawei.com>,
	"Gerd Hoffmann" <kraxel@redhat.com>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Fam Zheng" <fam@euphon.net>,
	"Raphael Norwitz" <raphael.norwitz@nutanix.com>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [PATCH v2 0/3] virtio: increase VIRTQUEUE_MAX_SIZE to 32k
Date: Tue, 5 Oct 2021 07:19:43 -0400	[thread overview]
Message-ID: <20211005071300-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <3198289.vhBqKWSW6W@silver>

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
> 



  reply	other threads:[~2021-10-05 11:19 UTC|newest]

Thread overview: 97+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-04 19:38 [Virtio-fs] [PATCH v2 0/3] virtio: increase VIRTQUEUE_MAX_SIZE to 32k Christian Schoenebeck
2021-10-04 19:38 ` Christian Schoenebeck
2021-10-04 19:38 ` [Virtio-fs] [PATCH v2 1/3] virtio: turn VIRTQUEUE_MAX_SIZE into a variable Christian Schoenebeck
2021-10-04 19:38   ` Christian Schoenebeck
2021-10-05  7:36   ` [Virtio-fs] " Greg Kurz
2021-10-05  7:36     ` Greg Kurz
2021-10-05 12:45   ` [Virtio-fs] " Stefan Hajnoczi
2021-10-05 12:45     ` Stefan Hajnoczi
2021-10-05 13:15     ` [Virtio-fs] " Christian Schoenebeck
2021-10-05 13:15       ` Christian Schoenebeck
2021-10-05 15:10       ` [Virtio-fs] " Stefan Hajnoczi
2021-10-05 15:10         ` Stefan Hajnoczi
2021-10-05 16:32         ` [Virtio-fs] " Christian Schoenebeck
2021-10-05 16:32           ` Christian Schoenebeck
2021-10-06 11:06           ` [Virtio-fs] " Stefan Hajnoczi
2021-10-06 11:06             ` Stefan Hajnoczi
2021-10-06 12:50             ` [Virtio-fs] " Christian Schoenebeck
2021-10-06 12:50               ` Christian Schoenebeck
2021-10-06 14:42               ` [Virtio-fs] " Stefan Hajnoczi
2021-10-06 14:42                 ` Stefan Hajnoczi
2021-10-07 13:09                 ` [Virtio-fs] " Christian Schoenebeck
2021-10-07 13:09                   ` Christian Schoenebeck
2021-10-07 15:18                   ` [Virtio-fs] " Stefan Hajnoczi
2021-10-07 15:18                     ` Stefan Hajnoczi
2021-10-08 14:48                     ` [Virtio-fs] " Christian Schoenebeck
2021-10-08 14:48                       ` Christian Schoenebeck
2021-10-04 19:38 ` [Virtio-fs] [PATCH v2 2/3] virtio: increase VIRTQUEUE_MAX_SIZE to 32k Christian Schoenebeck
2021-10-04 19:38   ` Christian Schoenebeck
2021-10-05  7:16   ` [Virtio-fs] " Michael S. Tsirkin
2021-10-05  7:16     ` Michael S. Tsirkin
2021-10-05  7:35     ` [Virtio-fs] " Greg Kurz
2021-10-05  7:35       ` Greg Kurz
2021-10-05 11:17     ` [Virtio-fs] " Christian Schoenebeck
2021-10-05 11:17       ` Christian Schoenebeck
2021-10-05 11:24       ` [Virtio-fs] " Michael S. Tsirkin
2021-10-05 11:24         ` Michael S. Tsirkin
2021-10-05 12:01         ` [Virtio-fs] " Christian Schoenebeck
2021-10-05 12:01           ` Christian Schoenebeck
2021-10-04 19:38 ` [Virtio-fs] [PATCH v2 3/3] virtio-9p-device: switch to 32k max. transfer size Christian Schoenebeck
2021-10-04 19:38   ` Christian Schoenebeck
2021-10-05  7:38 ` [Virtio-fs] [PATCH v2 0/3] virtio: increase VIRTQUEUE_MAX_SIZE to 32k David Hildenbrand
2021-10-05  7:38   ` David Hildenbrand
2021-10-05 11:10   ` [Virtio-fs] " Christian Schoenebeck
2021-10-05 11:10     ` Christian Schoenebeck
2021-10-05 11:19     ` Michael S. Tsirkin [this message]
2021-10-05 11:19       ` Michael S. Tsirkin
2021-10-05 11:43       ` [Virtio-fs] " Christian Schoenebeck
2021-10-05 11:43         ` Christian Schoenebeck
2021-10-07  5:23 ` [Virtio-fs] " Stefan Hajnoczi
2021-10-07  5:23   ` Stefan Hajnoczi
2021-10-07 12:51   ` [Virtio-fs] " Christian Schoenebeck
2021-10-07 12:51     ` Christian Schoenebeck
2021-10-07 15:42     ` [Virtio-fs] " Stefan Hajnoczi
2021-10-07 15:42       ` Stefan Hajnoczi
2021-10-08  7:25       ` [Virtio-fs] " Greg Kurz
2021-10-08  7:25         ` Greg Kurz
2021-10-08  8:27         ` [Virtio-fs] " Greg Kurz
2021-10-08 14:24         ` Christian Schoenebeck
2021-10-08 14:24           ` Christian Schoenebeck
2021-10-08 16:08           ` [Virtio-fs] " Christian Schoenebeck
2021-10-08 16:08             ` Christian Schoenebeck
2021-10-21 15:39             ` [Virtio-fs] " Christian Schoenebeck
2021-10-21 15:39               ` Christian Schoenebeck
2021-10-25 10:30               ` [Virtio-fs] " Stefan Hajnoczi
2021-10-25 10:30                 ` Stefan Hajnoczi
2021-10-25 15:03                 ` [Virtio-fs] " Christian Schoenebeck
2021-10-25 15:03                   ` Christian Schoenebeck
2021-10-28  9:00                   ` [Virtio-fs] " Stefan Hajnoczi
2021-10-28  9:00                     ` Stefan Hajnoczi
2021-11-01 20:29                     ` [Virtio-fs] " Christian Schoenebeck
2021-11-01 20:29                       ` Christian Schoenebeck
2021-11-03 11:33                       ` [Virtio-fs] " Stefan Hajnoczi
2021-11-03 11:33                         ` Stefan Hajnoczi
2021-11-04 14:41                         ` [Virtio-fs] " Christian Schoenebeck
2021-11-04 14:41                           ` Christian Schoenebeck
2021-11-09 10:56                           ` [Virtio-fs] " Stefan Hajnoczi
2021-11-09 10:56                             ` Stefan Hajnoczi
2021-11-09 13:09                             ` [Virtio-fs] " Christian Schoenebeck
2021-11-09 13:09                               ` Christian Schoenebeck
2021-11-10 10:05                               ` [Virtio-fs] " Stefan Hajnoczi
2021-11-10 10:05                                 ` Stefan Hajnoczi
2021-11-10 13:14                                 ` [Virtio-fs] " Christian Schoenebeck
2021-11-10 13:14                                   ` Christian Schoenebeck
2021-11-10 15:14                                   ` [Virtio-fs] " Stefan Hajnoczi
2021-11-10 15:14                                     ` Stefan Hajnoczi
2021-11-10 15:53                                     ` [Virtio-fs] " Christian Schoenebeck
2021-11-10 15:53                                       ` Christian Schoenebeck
2021-11-11 16:31                                       ` [Virtio-fs] " Stefan Hajnoczi
2021-11-11 16:31                                         ` Stefan Hajnoczi
2021-11-11 17:54                                         ` [Virtio-fs] " Christian Schoenebeck
2021-11-11 17:54                                           ` Christian Schoenebeck
2021-11-15 11:54                                           ` [Virtio-fs] " Stefan Hajnoczi
2021-11-15 11:54                                             ` Stefan Hajnoczi
2021-11-15 14:32                                             ` [Virtio-fs] " Christian Schoenebeck
2021-11-15 14:32                                               ` Christian Schoenebeck
2021-11-16 11:13                                               ` [Virtio-fs] " Stefan Hajnoczi
2021-11-16 11:13                                                 ` Stefan Hajnoczi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211005071300-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=amit@kernel.org \
    --cc=arei.gonglei@huawei.com \
    --cc=david@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=fam@euphon.net \
    --cc=hreitz@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=lvivier@redhat.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu_oss@crudebyte.com \
    --cc=raphael.norwitz@nutanix.com \
    --cc=virtio-fs@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.