All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Savir, Gil" <gil.savir@intel.com>
Cc: "virtio-comment@lists.oasis-open.org"
	<virtio-comment@lists.oasis-open.org>,
	"Elmaleh, Liron" <liron.elmaleh@intel.com>,
	cunming.liang@intel.com
Subject: Re: [virtio-comment] VirtIO spec issue - Available Buffer Notification Suppression
Date: Mon, 11 Feb 2019 01:58:09 -0500	[thread overview]
Message-ID: <20190211014709-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <54DB94AE64EDA14BAB6A1E9641A26B011AC3CFFB@hasmsx109.ger.corp.intel.com>

On Thu, Jan 31, 2019 at 01:16:29PM +0000, Savir, Gil wrote:
> Hi,
> 
>  
> 
> If VIRTIO_F_EVENT_IDX feature bit is negotiated, then Available Buffer
> Notification Suppression mechanism used is avail event (not flags).
> 
> The spec (both v1.0 / v1.1-draft) states that the device MAY use this mechanism
> (Paragraph 2.4.9.2 / 2.6.10.2 respectively).
> 
> This statement implies that the device may choose not to use this suppression
> mechanism (even if VIRTIO_F_EVENT_IDX was negotiated).
> 
>  
> 
> However – there’s no way for the device to inform the driver that he is not
> using avail_event.
> 
> As consequence, since there will be a default value in avail_event (probably
> 0x0), then the driver will always assume that it has to send notify “once-per
> ring”.


No I think this part is wrong, pls see below.


> This will render performance futile, or force the device to actively update
> avail_event.
> 
>  
> 
> Is there a way for the device to inform the driver that he is not using
> avail_event (and I missed it)?
> 
>  
> 
> If yes, than my apologies for wasting your time.
> 
> If no, then I suggest one of the following:
> 
> ·         Either, to change the “MAY” (referred above) to “MUST”,
> 

Thanks for the feedback!

So we are talking about split queues.

If avail_event is never set and remains 0, driver will send
notifications every time index wraps around to 0, which
would be every 2^16.

This is I think expected since the spec says:

The device MUST handle spurious notifications from the driver.

2^16 does not seem excessive so I don't think it will render performance
futile.

> ·        Or, to add way for the device to inform the driver that he is not
> using avail_event (flag /certain reserved value in avail_event /other
> mechanism).
> 
>  
> 
> Thanks,
> 
> Gil Savir
> 
> Intel Corporation

It might be a good addition to spec, probably along the lines
of an option to send notifications on
even suppression changes (which was proposed in the past, but
was not included due to lack of time).

-- 
MST

This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/


  reply	other threads:[~2019-02-11  6:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-31 13:16 [virtio-comment] VirtIO spec issue - Available Buffer Notification Suppression Savir, Gil
2019-02-11  6:58 ` Michael S. Tsirkin [this message]
2019-02-11  7:02   ` Michael S. Tsirkin
2019-02-21  8:57     ` Savir, Gil
2019-02-22  1:28       ` Michael S. Tsirkin
2019-02-26 20:30         ` Michael S. Tsirkin

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=20190211014709-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=cunming.liang@intel.com \
    --cc=gil.savir@intel.com \
    --cc=liron.elmaleh@intel.com \
    --cc=virtio-comment@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.