All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikos Dragazis <ndragazis@arrikto.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: "Stefan Hajnoczi" <stefanha@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	virtio-dev@lists.oasis-open.org
Subject: Re: [virtio-dev] [PATCH v5 01/10] vhost-user: add vhost-user device type
Date: Fri, 24 Jul 2020 20:31:48 +0300	[thread overview]
Message-ID: <f6e7491b-127e-30e3-99ca-de1aa8c6527e@arrikto.com> (raw)
In-Reply-To: <20200724103627-mutt-send-email-mst@kernel.org>

On 24/7/20 5:41 μ.μ., Michael S. Tsirkin wrote:

> On Fri, Jul 17, 2020 at 10:26:35AM +0100, Stefan Hajnoczi wrote:
>>>> +The following additional resources exist:
>>>> +\begin{description}
>>>> +  \item[Doorbells] The driver signals the vhost-user master through doorbells.  The signal does not carry any data, it is purely an event.
>>>> +  \item[Notifications] The vhost-user master signals the driver for events besides virtqueue activity and configuration changes by sending notifications.
>>> What is the difference between a doorbell and a notification?
>> Doorbells allow the driver to signal the device (i.e. device hardware
>> registers that the driver writes to).
>>
>> Notifications allow the driver to be signalled by the device (i.e. MSI-X
>> interrupts that the driver handles).
>>
>> The more abstract "doorbell" and "notification" terms are used instead
>> of hardware registers and interrupts because transports other than PCI
>> may want to support these features too.
> I think notification and doorbell are a bit too generic of a name.
>
> What we have is:
> available buffer notifications, used buffer
> notifications, configuration change notifications.

The problem with the virtio-vhost-user device is that it must be able to
exchange notifications (with the driver) that have nothing to do with
the notification types that you mentioned. Specifically, the
virtio-vhost-user device must be able to send/receive notifications
regarding activity on the vhost-user virtqueues.

The vhost-user virtqueues are not processed by the virtio-vhost-user
device and they have nothing to do with the RX/TX virtqueues of the
virtio-vhost-user device. I think this is the main reason why we don't
want to use the existing registers that we use for virtqueue
notifications.

So, my point is that we could extend the notion of a "notification".
A notification could be either one of the following:

1. available buffer notification
2. used buffer notification
3. configuration change notification
4. driver-to-device notification for other purposes
5. device-to-driver notification for other purposes

>
>
> So how about XXX notifications for both of these things?
> Where XXX explains what is the reason for triggering each
> type of notification.

I guess Stefan introduced the term "doorbell" because it is a widely
used term (e.g., in NVMe devices) and I think it is a pretty good
term. However, I agree that the vague term "notification" may cause
confusion.

Replacing "doorbells" and "notifications" with "XXX notifications"
sounds good. I can't think of some good terms for XXX right now.
Feel free to propose.

>
> It says "besides virtqueue activity and configuration changes" -
> what exactly is there?
>

As I said above, it is about available buffers on the vhost-user
virtqueues. But the vhost-user virtqueues are not related by any means
with the virtio-vhost-user device, so a notification resource in the
virtio-vhost-user device does not fit in the current definition of a
notification in virtio. It is something completely different.

---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


  reply	other threads:[~2020-07-24 17:31 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-18 20:37 [virtio-dev] [PATCH v5 00/10] introduce virtio vhost-user backend device type Nikos Dragazis
2020-05-18 20:37 ` [virtio-dev] [PATCH v5 01/10] vhost-user: add vhost-user " Nikos Dragazis
2020-07-16 16:45   ` Alex Bennée
2020-07-17  9:26     ` Stefan Hajnoczi
2020-07-17 10:28       ` Alex Bennée
2020-07-17 11:17       ` Nikos Dragazis
2020-07-20  9:37         ` Alex Bennée
2020-07-21 11:42           ` Nikos Dragazis
2020-07-23  6:15         ` Stefan Hajnoczi
2020-07-24 13:14           ` Nikos Dragazis
2020-07-24 14:41       ` Michael S. Tsirkin
2020-07-24 17:31         ` Nikos Dragazis [this message]
2020-07-27 12:25           ` Stefan Hajnoczi
2020-07-27 18:59             ` Nikos Dragazis
2020-07-29 13:52               ` Michael S. Tsirkin
2020-07-29 21:05                 ` Nikos Dragazis
2020-08-24 14:43                   ` Nikos Dragazis
2020-07-17 16:52     ` Nikos Dragazis
2020-05-18 20:37 ` [virtio-dev] [PATCH v5 02/10] vhost-user: minor fixes Nikos Dragazis
2020-07-16 16:48   ` Alex Bennée
2020-07-17  9:27   ` Stefan Hajnoczi
2020-05-18 20:37 ` [virtio-dev] [PATCH v5 03/10] vhost-user: add requirements for the notification capability Nikos Dragazis
2020-07-17  9:34   ` Stefan Hajnoczi
2020-07-17 16:02     ` Nikos Dragazis
2020-07-23  6:16       ` Stefan Hajnoczi
2020-05-18 20:37 ` [virtio-dev] [PATCH v5 04/10] vhost-user: update shared memory capability Nikos Dragazis
2020-07-17  9:36   ` Stefan Hajnoczi
2020-07-17 15:00     ` Nikos Dragazis
2020-05-18 20:37 ` [virtio-dev] [PATCH v5 05/10] vhost-user: add conformance targets and clauses Nikos Dragazis
2020-07-17  9:37   ` Stefan Hajnoczi
2020-07-20 15:01   ` Alex Bennée
2020-05-18 20:37 ` [virtio-dev] [PATCH v5 06/10] vhost-user: change the device id Nikos Dragazis
2020-07-20 15:03   ` Alex Bennée
2020-05-18 20:37 ` [virtio-dev] [PATCH v5 07/10] vhost-user: minor fix on status register Nikos Dragazis
2020-07-17  9:39   ` Stefan Hajnoczi
2020-05-18 20:37 ` [virtio-dev] [PATCH v5 08/10] vhost-user: remove the extra PCI capabilities Nikos Dragazis
2020-07-17  9:48   ` Stefan Hajnoczi
2020-07-17 15:03     ` Nikos Dragazis
2020-07-23  6:29       ` Stefan Hajnoczi
2020-07-24 13:41         ` Nikos Dragazis
2020-05-18 20:37 ` [virtio-dev] [PATCH v5 09/10] vhost-user: intercept slave's reply to VHOST_USER_GET_PROTOCOL_FEATURES Nikos Dragazis
2020-07-17  9:57   ` Stefan Hajnoczi
2020-07-17 15:37     ` Nikos Dragazis
2020-07-23  6:32       ` Stefan Hajnoczi
2020-05-18 20:37 ` [virtio-dev] [PATCH v5 10/10] vhost-user: clarify that we are talking about slave-initiated messages Nikos Dragazis
2020-07-17  9:59   ` Stefan Hajnoczi
2020-06-24 18:01 ` [virtio-dev] [PATCH v5 00/10] introduce virtio vhost-user backend device type Nikos Dragazis

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=f6e7491b-127e-30e3-99ca-de1aa8c6527e@arrikto.com \
    --to=ndragazis@arrikto.com \
    --cc=alex.bennee@linaro.org \
    --cc=mst@redhat.com \
    --cc=stefanha@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.