OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [virtio] [PATCH v7 01/11] content: move 1.0 queue format out to a separate section

On 01/23/2018 01:01 AM, Michael S. Tsirkin wrote:
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
>  content.tex | 25 ++++++++++++++++++++++++-
>  1 file changed, 24 insertions(+), 1 deletion(-)
> diff --git a/content.tex b/content.tex
> index c7ef7fd..4483a4b 100644
> --- a/content.tex
> +++ b/content.tex
> @@ -230,7 +230,30 @@ result.
>  The mechanism for bulk data transport on virtio devices is
>  pretentiously called a virtqueue. Each device can have zero or more
>  virtqueues\footnote{For example, the simplest network device has one virtqueue for
> -transmit and one for receive.}.  Each queue has a 16-bit queue size
> +transmit and one for receive.}.
> +
> +Driver makes requests available to device by adding
> +an available buffer to the queue - i.e. adding a buffer
> +describing the request to a virtqueue, and optionally triggering
> +a driver event - i.e. sending a notification to the device.
> +
> +Device executes the requests and - when complete - adds
> +a used buffer to the queue - i.e. lets the driver
> +know by marking the buffer as used. Device can then trigger
> +a device event - i.e. send an interrupt to the driver.
> +

Here I seem to recognize my suggestion about describing the
relationship between virtqueue buffers and requests. But none
of the terms your are using are defined yet, so assuming linear
reading, this may not be the best place to establish that relationship.

Furthermore I think the usage of the term 'buffer' got even messier
that in v1.0. I will elaborate on that later.

> +For queue operation detail, see \ref{sec:Basic Facilities of a Virtio Device / Split Virtqueues}~\nameref{sec:Basic Facilities of a Virtio Device / Split Virtqueues}.
> +
> +\section{Split Virtqueues}\label{sec:Basic Facilities of a Virtio Device / Split Virtqueues}
> +The split virtqueue format is the original format used by legacy
> +virtio devices.

All v1.0 devices and drivers are using split too not only legacy (aka pre v1.0). 

>  The split virtqueue format separates the
> +virtqueue into several parts, where each part is write-able by
> +either the driver or the device, but not both. Multiple
> +locations need to be updated when making a buffer available
> +and when marking it as used.
> +

If we assume 3 parts (available ring, used ring and descriptor table),
then the two last sentences are contradictory: as one of three would have
to be updated by both the device and the driver. Or did I misunderstand

I think, the purpose of this paragraph is to distinguish the split
form the packed. We probably don't need these additions to understand
'split'. I would rather see a discussion on the two formats in the
common (2.4) virtqueue section.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]