From: Christian Schoenebeck <qemu_oss@crudebyte.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: virtio-comment@lists.oasis-open.org,
Cornelia Huck <cohuck@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>, Greg Kurz <groug@kaod.org>,
Dominique Martinet <asmadeus@codewreck.org>,
Halil Pasic <pasic@linux.ibm.com>
Subject: Re: [virtio-comment] [PATCH v3 1/4] Add VIRTIO_RING_F_INDIRECT_SIZE
Date: Sat, 19 Mar 2022 13:00:28 +0100 [thread overview]
Message-ID: <8451025.v97J4D4Zi3@silver> (raw)
In-Reply-To: <CAJWYKVxGygN42ukOE9eoT9ksK9zxwJD5d0jy--_T6=5d=eBoEA@mail.gmail.com>
On Samstag, 19. März 2022 10:33:49 CET Michael S. Tsirkin wrote:
> On Wed, Mar 16, 2022, 15:47 Christian Schoenebeck <qemu_oss@crudebyte.com>
>
> wrote:
> > This new feature flag allows to decouple the maximum amount of
> > descriptors in indirect descriptor tables from the Queue Size.
>
> if we are extending these limits, I suggest reusing the feature flag to
> also add a limit on total s/g list size. making it separate from queue size
> was requested a while ago.
What do you mean with "total s/g list size"? The maximum bulk data size per
message? Sum of both in and out s/g lists' bulk data or only for one of them?
Or maximum size of exactly only one memory segment?
And are you suggesting this should become part of this series already?
> > The new term "Queue Indirect Size" is introduced for this purpose,
> > which is a transport specific configuration whose negotiation is
> > further specified for each transport with subsequent patches.
> >
> > Fixes: https://github.com/oasis-tcs/virtio-spec/issues/122
> > Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
> > Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
> > ---
> >
> > content.tex | 32 ++++++++++++++++++++++++++++++--
> > packed-ring.tex | 2 +-
> > split-ring.tex | 8 ++++++--
> > 3 files changed, 37 insertions(+), 5 deletions(-)
> >
> > diff --git a/content.tex b/content.tex
> > index c6f116c..685525d 100644
> > --- a/content.tex
> > +++ b/content.tex
> > @@ -99,10 +99,10 @@ \section{Feature Bits}\label{sec:Basic Facilities of a
> > Virtio Device / Feature B
> >
> > \begin{description}
> > \item[0 to 23, and 50 to 127] Feature bits for the specific device type
> >
> > -\item[24 to 40] Feature bits reserved for extensions to the queue and
> > +\item[24 to 41] Feature bits reserved for extensions to the queue and
> >
> > feature negotiation mechanisms
> >
> > -\item[41 to 49, and 128 and above] Feature bits reserved for future
> > extensions.
> > +\item[42 to 49, and 128 and above] Feature bits reserved for future
> > extensions.
> >
> > \end{description}
> >
> > \begin{note}
> >
> > @@ -1051,6 +1051,10 @@ \subsubsection{Common configuration structure
> > layout}\label{sec:Virtio Transport
> >
> > present either a value of 0 or a power of 2 in
> > \field{queue_size}.
> >
> > +If VIRTIO_RING_F_INDIRECT_SIZE has been negotiated, the device MUST
> > provide the
> > +Queue Indirect Size supported by device, which is a transport specific
> > +configuration. It MUST allow the driver to set a lower value.
> > +
> >
> > \drivernormative{\paragraph}{Common configuration structure
> >
> > layout}{Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout
> > / Common configuration structure layout}
> >
> > The driver MUST NOT write to \field{device_feature}, \field{num_queues},
> >
> > \field{config_generation}, \field{queue_notify_off} or
> > \field{queue_notify_data}.
> > @@ -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.
>
> spect does not call these slots elsewhere.
Yes, I intentionally used "vring slot" instead of "buffer" as I find the
latter too vague in this context. A "buffer" can be a memory segment, a set of
memory segments and what not. "vring slot" OTOH makes it clear that it is
about exactly one, atomic pointer (hence with fixed size) in a Ring Buffer, as
depicted in the ASCII illustration here:
https://github.com/oasis-tcs/virtio-spec/issues/122
The maximum amount of vring slots is therefore the maximum amount of messages
that can be emplaced into a Ring Buffer, independent of any "bulk data buffer
size".
>
>
> +
>
> > + 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
> > + be negotiated if VIRTIO_RING_F_INDIRECT_SIZE was negotiated to
> > subsequently
> > + negotiate the actual amount of maximum indirect descriptors supported
> > + by both sides.
>
> still not sure what exactly is the value. e.g. in a buffer including
> indirect and direct descriptors.
>
> +
>
> > \end{description}
> >
> > \drivernormative{\section}{Reserved Feature Bits}{Reserved Feature Bits}
> >
> > diff --git a/packed-ring.tex b/packed-ring.tex
> > index a9e6c16..e26d112 100644
> > --- a/packed-ring.tex
> > +++ b/packed-ring.tex
> > @@ -195,7 +195,7 @@ \subsection{Scatter-Gather Support}
> >
> > The device limits the number of descriptors in a list through a
> > transport-specific and/or device-specific value. If not limited,
> > the maximum number of descriptors in a list is the virt queue
> >
> > -size.
> > +size unless the VIRTIO_RING_F_INDIRECT_SIZE feature has been negotiated.
> >
> > \subsection{Next Flag: Descriptor Chaining}
> > \label{sec:Packed Virtqueues / Next Flag: Descriptor Chaining}
> >
> > diff --git a/split-ring.tex b/split-ring.tex
> > index de94038..eaa90c3 100644
> > --- a/split-ring.tex
> > +++ b/split-ring.tex
> > @@ -268,8 +268,12 @@ \subsubsection{Indirect Descriptors}\label{sec:Basic
> > Facilities of a Virtio Devi
> >
> > set the VIRTQ_DESC_F_INDIRECT flag within an indirect descriptor (ie.
> > only
> > one table per descriptor).
> >
> > -A driver MUST NOT create a descriptor chain longer than the Queue Size of
> > -the device.
>
> +If VIRTIO_RING_F_INDIRECT_SIZE has not been negotiated, the driver MUST
>
> > +NOT create a descriptor chain longer than the Queue Size of the device.
> > +
> > +If VIRTIO_RING_F_INDIRECT_SIZE has been negotiated, the number of
> > +descriptors per indirect descriptor table MUST NOT exceed the negotiated
> > +Queue Indirect Size.
>
> it is not negotiated is it?
What makes you think it is not negotiated?
>
> > A driver MUST NOT set both VIRTQ_DESC_F_INDIRECT and VIRTQ_DESC_F_NEXT
> > in \field{flags}.
> >
> > --
> > 2.30.2
> >
> >
> >
> >
> >
> > This publicly archived list offers a means to provide input to the
> > OASIS Virtual I/O Device (VIRTIO) TC.
> >
> > In order to verify user consent to the Feedback License terms and
> > to minimize spam in the list archive, subscription is required
> > before posting.
> >
> > Subscribe: virtio-comment-subscribe@lists.oasis-open.org
> > Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
> > List help: virtio-comment-help@lists.oasis-open.org
> > List archive: https://lists.oasis-open.org/archives/virtio-comment/
> > Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
> > List Guidelines:
> > https://www.oasis-open.org/policies-guidelines/mailing-lists
> > Committee: https://www.oasis-open.org/committees/virtio/
> > Join OASIS: https://www.oasis-open.org/join/
next prev parent reply other threads:[~2022-03-19 12:00 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-16 13:44 [PATCH v3 0/4] Add VIRTIO_RING_F_INDIRECT_SIZE and queue_indirect_size Christian Schoenebeck
2022-03-16 13:47 ` [PATCH v3 1/4] Add VIRTIO_RING_F_INDIRECT_SIZE Christian Schoenebeck
2022-03-17 13:40 ` [virtio-comment] " Cornelia Huck
2022-03-18 10:45 ` Christian Schoenebeck
2022-03-18 16:03 ` [virtio-comment] " Cornelia Huck
2022-03-19 9:33 ` [virtio-comment] " Michael S. Tsirkin
2022-03-19 12:00 ` Christian Schoenebeck [this message]
2022-03-20 12:31 ` Michael S. Tsirkin
2022-03-20 13:32 ` Christian Schoenebeck
2022-03-20 13:55 ` Michael S. Tsirkin
2022-03-20 15:17 ` Christian Schoenebeck
2022-03-20 16:06 ` Michael S. Tsirkin
2022-03-20 16:07 ` Michael S. Tsirkin
2022-03-20 17:43 ` Christian Schoenebeck
2022-03-20 21:52 ` Michael S. Tsirkin
2022-03-21 9:23 ` Christian Schoenebeck
2022-03-21 22:13 ` Michael S. Tsirkin
2022-03-23 10:20 ` Christian Schoenebeck
2022-03-23 12:35 ` Michael S. Tsirkin
2022-03-24 9:16 ` Christian Schoenebeck
2022-03-24 10:36 ` Michael S. Tsirkin
2022-03-24 11:11 ` Christian Schoenebeck
2022-03-24 11:16 ` Michael S. Tsirkin
2022-03-24 11:52 ` Christian Schoenebeck
2022-03-16 13:50 ` [PATCH v3 2/4] Add PCI configuration field "queue_indirect_size" Christian Schoenebeck
2022-03-16 14:41 ` [virtio-comment] " Christian Schoenebeck
2022-03-16 13:52 ` [PATCH v3 3/4] Add MMIO configuration register "QueueIndirectNum" Christian Schoenebeck
2022-03-16 13:55 ` [PATCH v3 4/4] Add CCW configuration field "indirect_num" Christian Schoenebeck
2022-03-17 14:12 ` [virtio-comment] " Cornelia Huck
2022-03-18 11:02 ` Christian Schoenebeck
2022-03-18 16:06 ` Halil Pasic
2022-03-19 10:12 ` Christian Schoenebeck
2022-03-21 16:36 ` Cornelia Huck
2022-03-22 1:56 ` Halil Pasic
2022-03-22 9:57 ` Cornelia Huck
2022-03-22 11:21 ` Halil Pasic
2022-03-18 16:10 ` Cornelia Huck
2022-03-19 10:23 ` Christian Schoenebeck
2022-03-21 16:25 ` Cornelia Huck
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=8451025.v97J4D4Zi3@silver \
--to=qemu_oss@crudebyte.com \
--cc=asmadeus@codewreck.org \
--cc=cohuck@redhat.com \
--cc=groug@kaod.org \
--cc=mst@redhat.com \
--cc=pasic@linux.ibm.com \
--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