From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: virtio-dev@lists.oasis-open.org, mszeredi@redhat.com, vgoyal@redhat.com
Subject: [virtio-dev] Re: [PATCH 2/2] virtio-fs: add notification queue
Date: Wed, 27 Nov 2019 10:45:24 +0000 [thread overview]
Message-ID: <20191127104524.GF3016@work-vm> (raw)
In-Reply-To: <20191122144824.483847-3-stefanha@redhat.com>
* Stefan Hajnoczi (stefanha@redhat.com) wrote:
> The FUSE protocol allows the file server (device) to initiate
> communication with the client (driver) using FUSE notify messages.
> Normally only the client can initiate communication. This feature is
> used to report asynchronous events that are not related to an in-flight
> request.
>
> This patch adds a notification queue that works like an rx queue in
> other types of device. The device can emit FUSE notify messages by
> using a buffer from this queue.
>
> This mechanism was designed by Vivek Goyal <vgoyal@redhat.com>.
>
> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> ---
> TODO:
> * Flow control? What happens when the notification queue is empty when
> the device wants to emit a message. We cannot assume unlimited
> device resources for holding back pending notifications. Eventually
> they will have to be dropped and/or the device needs to report an
> error.
> ---
> conformance.tex | 1 +
> virtio-fs.tex | 63 +++++++++++++++++++++++++++++++++++++++++--------
> 2 files changed, 54 insertions(+), 10 deletions(-)
>
> diff --git a/conformance.tex b/conformance.tex
> index 25d11ec..a43eea3 100644
> --- a/conformance.tex
> +++ b/conformance.tex
> @@ -190,6 +190,7 @@ \section{Conformance Targets}\label{sec:Conformance / Conformance Targets}
> \begin{itemize}
> \item \ref{drivernormative:Device Types / File System Device / Device configuration layout}
> \item \ref{drivernormative:Device Types / File System Device / Device Operation / Device Operation: High Priority Queue}
> +\item \ref{drivernormative:Device Types / File System Device / Device Operation / Device Operation: Notification Queue}
> \item \ref{drivernormative:Device Types / File System Device / Device Operation / Device Operation: DAX Window}
> \end{itemize}
>
> diff --git a/virtio-fs.tex b/virtio-fs.tex
> index 158d066..a94a377 100644
> --- a/virtio-fs.tex
> +++ b/virtio-fs.tex
> @@ -25,24 +25,33 @@ \subsection{Virtqueues}\label{sec:Device Types / File System Device / Virtqueues
>
> \begin{description}
> \item[0] hiprio
> -\item[1\ldots n] request queues
> +\item[1] notification queue
> +\item[2\ldots n] request queues
> \end{description}
>
> +The notification queue only exists if VIRTIO_FS_F_NOTIFICATION is set.
> +
> \subsection{Feature bits}\label{sec:Device Types / File System Device / Feature bits}
>
> -There are currently no feature bits defined.
> +\begin{description}
> +\item[VIRTIO_FS_F_NOTIFICATION (0)] Device has support for FUSE notify
> + messages. The notification queue is virtqueue 1.
> +\end{description}
>
> \subsection{Device configuration layout}\label{sec:Device Types / File System Device / Device configuration layout}
>
> -All fields of this configuration are always available.
> -
> \begin{lstlisting}
> struct virtio_fs_config {
> char tag[36];
> le32 num_request_queues;
> + le32 notify_buf_size;
> };
> \end{lstlisting}
>
> +The \field{tag} and \field{num_request_queues} fields are always available.
> +The \field{notify_buf_size} field is only available when
> +VIRTIO_FS_F_NOTIFICATION is set.
> +
> \begin{description}
> \item[\field{tag}] is the name associated with this file system. The tag is
> encoded in UTF-8 and padded with NUL bytes if shorter than the
> @@ -53,6 +62,8 @@ \subsection{Device configuration layout}\label{sec:Device Types / File System De
> there are no ordering guarantees between requests made available on
> different queues. Use of multiple queues is intended to increase
> performance.
> +\item[\field{notify_buf_size}] is the minimum number of bytes required for each
> + buffer in the notification queue.
> \end{description}
>
> \drivernormative{\subsubsection}{Device configuration layout}{Device Types / File System Device / Device configuration layout}
> @@ -65,13 +76,20 @@ \subsection{Device configuration layout}\label{sec:Device Types / File System De
>
> The device MUST set \field{num_request_queues} to 1 or greater.
>
> +The device MUST set \field{notify_buf_size} to be large enough to hold any of
> +the FUSE notify messages that this device emits.
> +
Is there some ordering requirement here to ensure that the device has
set notify_buf_size before the driver starts trying to populate the
queue with empties?
Dave
> \subsection{Device Initialization}\label{Device Types / File System Device / Device Initialization}
>
> -On initialization the driver first discovers the device's virtqueues. The FUSE
> -session is started by sending a FUSE\_INIT request as defined by the FUSE
> -protocol on one request virtqueue. All virtqueues provide access to the same
> -FUSE session and therefore only one FUSE\_INIT request is required regardless
> -of the number of available virtqueues.
> +On initialization the driver first discovers the device's virtqueues.
> +
> +The driver populates the notification queue with buffers for receiving FUSE
> +notify messages if VIRTIO_FS_F_NOTIFICATION is set.
> +
> +The FUSE session is started by sending a FUSE\_INIT request as defined by the
> +FUSE protocol on one request virtqueue. All virtqueues provide access to the
> +same FUSE session and therefore only one FUSE\_INIT request is required
> +regardless of the number of available virtqueues.
>
> \subsection{Device Operation}\label{sec:Device Types / File System Device / Device Operation}
>
> @@ -88,7 +106,8 @@ \subsection{Device Operation}\label{sec:Device Types / File System Device / Devi
> full.
> \end{itemize}
>
> -Note that FUSE notification requests are not supported.
> +FUSE notify messages are received on the notification queue if
> +VIRTIO_FS_F_NOTIFICATION is set.
>
> \subsubsection{Device Operation: Request Queues}\label{sec:Device Types / File System Device / Device Operation / Device Operation: Request Queues}
>
> @@ -179,6 +198,30 @@ \subsubsection{Device Operation: High Priority Queue}\label{sec:Device Types / F
>
> The driver MUST anticipate that request queues are processed concurrently with the hiprio queue.
>
> +\subsubsection{Device Operation: Notification Queue}\label{sec:Device Types / File System Device / Device Operation / Device Operation: Notification Queue}
> +
> +The notification queue is populated with buffers by the driver and these
> +buffers are used by the device to emit FUSE notify messages. Notification
> +queue buffer layout is as follows:
> +
> +\begin{lstlisting}
> +struct virtio_fs_notify {
> + // Device-writable part
> + struct fuse_out_header out_hdr;
> + char outarg[notify_buf_size - sizeof(struct fuse_out_header)];
> +};
> +\end{lstlisting}
> +
> +\field{outarg} contains the FUSE notify message payload that depends on the
> +type of notification being emitted.
> +
> +\drivernormative{\paragraph}{Device Operation: Notification Queue}{Device Types / File System Device / Device Operation / Device Operation: Notification Queue}
> +
> +The driver MUST provide buffers of at least \field{notify_buf_size} bytes.
> +
> +The driver SHOULD replenish notification queue buffers sufficiently quickly so
> +that there is always at least one available buffer.
> +
> \subsubsection{Device Operation: DAX Window}\label{sec:Device Types / File System Device / Device Operation / Device Operation: DAX Window}
>
> FUSE\_READ and FUSE\_WRITE requests transfer file contents between the
> --
> 2.23.0
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
prev parent reply other threads:[~2019-11-27 10:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-22 14:48 [virtio-dev] [PATCH 0/2] virtio-fs: add notification queue Stefan Hajnoczi
2019-11-22 14:48 ` [virtio-dev] [PATCH 1/2] virtio-fs: add file system device to Conformance chapter Stefan Hajnoczi
2019-11-27 10:21 ` [virtio-dev] " Dr. David Alan Gilbert
2019-11-22 14:48 ` [virtio-dev] [PATCH 2/2] virtio-fs: add notification queue Stefan Hajnoczi
2019-11-27 10:45 ` Dr. David Alan Gilbert [this message]
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=20191127104524.GF3016@work-vm \
--to=dgilbert@redhat.com \
--cc=mszeredi@redhat.com \
--cc=stefanha@redhat.com \
--cc=vgoyal@redhat.com \
--cc=virtio-dev@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.