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

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

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


Subject: Re: [virtio-dev] [PATCH v5 01/10] vhost-user: add vhost-user device type


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.


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