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: 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: Sun, 20 Mar 2022 08:31:51 -0400	[thread overview]
Message-ID: <20220320082410-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <8451025.v97J4D4Zi3@silver>

On Sat, Mar 19, 2022 at 01:00:28PM +0100, Christian Schoenebeck wrote:
> 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?

I don't really know what does "bulk data size" mean. Suggest we use
terminology from the spec. A buffer includes a group of direct and/or
indirect descriptors, in turn indirect descriptors point to direct
descriptors.


What has been requested a while is ability to limit per vq the
# of direct descriptors in a buffer.


Since IIUC what you want to do is allow more descriptors
than VQ size, then one way to achieve that is just to have
a per VQ limit on descriptor size and have that limit > VQ size.

Another thing related is that people wanted to block indirect
descriptors for some VQs. Not yet sure how to combine that
with this proposal, worth thinking about.


> 
> And are you suggesting this should become part of this series already?

yes since it's touching mostly same areas in the spec.

> > > 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/
> 


  reply	other threads:[~2022-03-20 12:31 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
2022-03-20 12:31       ` Michael S. Tsirkin [this message]
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=20220320082410-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=asmadeus@codewreck.org \
    --cc=cohuck@redhat.com \
    --cc=groug@kaod.org \
    --cc=pasic@linux.ibm.com \
    --cc=qemu_oss@crudebyte.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 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.