Discussion of the VIRTIO specification
 help / color / mirror / Atom feed
From: Christian Schoenebeck <qemu_oss@crudebyte.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: virtio-comment@lists.oasis-open.org,
	Cornelia Huck <cohuck@redhat.com>, Greg Kurz <groug@kaod.org>,
	Dominique Martinet <asmadeus@codewreck.org>
Subject: Re: [PATCH v2 1/4] Add VIRTIO_RING_F_INDIRECT_SIZE
Date: Thu, 10 Mar 2022 17:20:19 +0100	[thread overview]
Message-ID: <24220875.zXfpC7KmYo@silver> (raw)
In-Reply-To: <YioR2KrQiy4OP+nD@stefanha-x1.localdomain>

On Donnerstag, 10. März 2022 15:57:28 CET Stefan Hajnoczi wrote:
> On Mon, Feb 21, 2022 at 05:25:00PM +0100, Christian Schoenebeck wrote:
> > @@ -6847,6 +6851,30 @@ \chapter{Reserved Feature Bits}\label{sec:Reserved
> > Feature Bits}> 
> >    that the driver can reset a queue individually.
> >    See \ref{sec:Basic Facilities of a Virtio Device / Virtqueues /
> >    Virtqueue Reset}.> 
> > +  \item[VIRTIO_RING_F_INDIRECT_SIZE(41)] This feature indicates that the
> > +  Queue Indirect Size, i.e. the maximum amount of descriptors in indirect
> > +  descriptor tables, is independent from the Queue Size.
> > +
> > +  Without this feature, the Queue Size limits the length of the
> > descriptor
> > +  chain, including indirect descriptor tables as in \ref{sec:Basic
> > Facilities of +  a Virtio Device / Virtqueues / The Virtqueue Descriptor
> > Table / Indirect +  Descriptors}, i.e. both the maximum amount of slots
> > in the vring and the +  actual bulk data size transmitted per vring slot.
> > +
> > +  With this feature enabled, the Queue Size only limits the maximum
> > amount
> > +  of slots in the vring, but does not limit the actual bulk data size
> > +  being transmitted when indirect descriptors are used. Decoupling these
> > +  two configuration parameters this way not only allows much larger bulk
> > data +  being transferred per vring slot, but also avoids complicated
> > synchronization +  mechanisms if the device only supports a very small
> > amount of vring slots. Due +  to the 16-bit size of a descriptor's "next"
> > field there is still an absolute +  limit of $2^{16}$ descriptors per
> > indirect descriptor table. However the +  actual maximum amount supported
> > by either device or driver might be less, +  and therefore the bus
> > specific Queue Indirect Size value MUST additionally
> s/bus/transport/
> 
> Otherwise:
> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

I'll change that in v3. Thanks!

Best regards,
Christian Schoenebeck



  reply	other threads:[~2022-03-10 16:20 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-21 16:22 [virtio-comment] [PATCH v2 0/4] Add VIRTIO_RING_F_INDIRECT_SIZE and queue_indirect_size Christian Schoenebeck
2022-02-21 16:25 ` [virtio-comment] [PATCH v2 1/4] Add VIRTIO_RING_F_INDIRECT_SIZE Christian Schoenebeck
2022-03-10 14:57   ` Stefan Hajnoczi
2022-03-10 16:20     ` Christian Schoenebeck [this message]
2022-02-21 16:27 ` [PATCH v2 2/4] Add PCI configuration field "queue_indirect_size" Christian Schoenebeck
2022-03-10 15:04   ` [virtio-comment] " Stefan Hajnoczi
2022-02-21 16:58 ` [PATCH v2 3/4] Add MMIO configuration register "QueueIndirectNum" Christian Schoenebeck
2022-03-10 15:23   ` Stefan Hajnoczi
2022-02-21 17:01 ` [PATCH v2 4/4] Add CCW configuration field "indirect_num" to vq_info_block Christian Schoenebeck
2022-03-10 15:26   ` Stefan Hajnoczi
2022-03-10 16:09     ` [virtio-comment] " Cornelia Huck
2022-03-11  8:53       ` Christian Schoenebeck
2022-03-11  9:21         ` [virtio-comment] " Cornelia Huck
2022-03-11 11:15           ` Halil Pasic
2022-03-11 12:09             ` [virtio-comment] " Christian Schoenebeck
2022-03-10 16:09     ` Christian Schoenebeck
2022-03-09 14:58 ` [virtio-comment] [PATCH v2 0/4] Add VIRTIO_RING_F_INDIRECT_SIZE and queue_indirect_size Christian Schoenebeck
2022-03-10 15:35   ` 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=24220875.zXfpC7KmYo@silver \
    --to=qemu_oss@crudebyte.com \
    --cc=asmadeus@codewreck.org \
    --cc=cohuck@redhat.com \
    --cc=groug@kaod.org \
    --cc=stefanha@redhat.com \
    --cc=virtio-comment@lists.oasis-open.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox