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: Thu, 30 Jul 2020 00:05:05 +0300	[thread overview]
Message-ID: <ea1dc7aa-80bf-21aa-c275-1e9f48f2360c@arrikto.com> (raw)
In-Reply-To: <20200729094956-mutt-send-email-mst@kernel.org>

On 29/7/20 4:52 μ.μ., Michael S. Tsirkin wrote:

> On Mon, Jul 27, 2020 at 09:59:36PM +0300, Nikos Dragazis wrote:
>> On 27/7/20 3:25 μ.μ., Stefan Hajnoczi wrote:
>>
>>> On Fri, Jul 24, 2020 at 08:31:48PM +0300, Nikos Dragazis wrote:
>>>> On 24/7/20 5:41 μ.μ., Michael S. Tsirkin wrote:
>>>>> On Fri, Jul 17, 2020 at 10:26:35AM +0100, Stefan Hajnoczi wrote:
>>>>> 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.
>>> Device-specific notifications and device-specific doorbells?
> Um. What does this mean exactly?
> Really I am guessing you are notifying about some kind of event.
> So let's call it according to this event then.

It's for available and used buffer notifications on the vhost-user
virtqueues. We don't want to use this name because it refers to a very
specific use case and, hence, it is too restrictive. What we want is to
introduce new types of notifications that will be generic enough so that
other future devices will be able to use them as well.

>>> I think these concepts should be part of the core VIRTIO device model so
>>> that other devices can also define device-specific
>>> notifications/doorbells in the future.
>>>
>>> Stefan
>> I think that Michael is OK with standardizing these resources, but he is
>> not really happy with the term "doorbell".
>>
>>  From the one hand, using the term "XXX notification" would be more
>> consistent with the virtio spec, since virtio already uses the term
>> "notification" for driver-to-device signaling regarding the virtqueues.
>>
>> On the other hand, I can't find something for XXX that would sound
>> better than "doorbell".
>>
>> But let's see what Michael has to say.
>>
>> Nikos
> "doorbells" is generally like available buffer notifications that we
> have in virtio. I am still not sure what does it mean in this context.
>

"doorbells" is more generic than available buffer notifications. It will
refer to any type of driver-to-device notification that will not be an
available buffer notification.

Think about the vendor-specific capabilities in PCI. They are there so
that a device manufacturer can implement non-standardized capabilities.
Similarly, doorbells will be there so that a device can support
driver-to-device notifications for other things except for available
buffers.

As an alternative to:

- device-specific doorbells
- device-specific notifications

I would also put the following names on the table:

- device-specific driver-to-device notifications
- device-specific device-to-driver notifications

but I like Stefan's better.

Nikos

---------------------------------------------------------------------
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-29 21:05 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
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 [this message]
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=ea1dc7aa-80bf-21aa-c275-1e9f48f2360c@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.