From: Tiwei Bie <tiwei.bie@intel.com>
To: mst@redhat.com, cohuck@redhat.com, stefanha@redhat.com,
pbonzini@redhat.com, jasowang@redhat.com,
pasic@linux.vnet.ibm.com, virtio-dev@lists.oasis-open.org
Cc: dan.daly@intel.com, cunming.liang@intel.com, zhihong.wang@intel.com
Subject: [virtio-dev] [RFC] content: tweak VIRTIO_F_IO_BARRIER
Date: Mon, 25 Jun 2018 20:24:42 +0800 [thread overview]
Message-ID: <20180625122442.22432-1-tiwei.bie@intel.com> (raw)
VIRTIO_F_IO_BARRIER was proposed recently to allow
drivers to do some optimizations when devices are
implemented in software. But it only covers barrier
related optimizations. Later investigations show
that, it could cover more. So this patch tweaks this
feature bit to tell the driver whether it can assume
the device is implemented in software and runs on
host CPU, and also renames this feature bit to
VIRTIO_F_REAL_DEVICE correspondingly.
Suggested-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Tiwei Bie <tiwei.bie@intel.com>
---
content.tex | 22 ++++++++++------------
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/content.tex b/content.tex
index be18234..5d6b977 100644
--- a/content.tex
+++ b/content.tex
@@ -5356,15 +5356,13 @@ Descriptors} and \ref{sec:Packed Virtqueues / Indirect Flag: Scatter-Gather Supp
\item[VIRTIO_F_IN_ORDER(35)] This feature indicates
that all buffers are used by the device in the same
order in which they have been made available.
- \item[VIRTIO_F_IO_BARRIER(36)] This feature indicates
- that the device needs the driver to use the barriers
- suitable for hardware devices. Some transports require
- barriers to ensure devices have a consistent view of
- memory. When devices are implemented in software a
- weaker form of barrier may be sufficient and yield
+ \item[VIRTIO_F_REAL_DEVICE(36)] This feature indicates
+ that the device doesn't allow the driver to assume the
+ device is implemented in software and runs on host CPU.
+ When devices are implemented in software and run on host
+ CPU, some optimizations can be done in drivers and yield
better performance. This feature indicates whether
- a stronger form of barrier suitable for hardware
- devices is necessary.
+ drivers can make this assumption.
\item[VIRTIO_F_SR_IOV(37)] This feature indicates that
the device supports Single Root I/O Virtualization.
Currently only PCI devices support this feature.
@@ -5383,9 +5381,9 @@ addresses to the device.
A driver SHOULD accept VIRTIO_F_RING_PACKED if it is offered.
-A driver SHOULD accept VIRTIO_F_IO_BARRIER if it is offered.
-If VIRTIO_F_IO_BARRIER has been negotiated, a driver MUST use
-the barriers suitable for hardware devices.
+A driver SHOULD accept VIRTIO_F_REAL_DEVICE if it is offered.
+If VIRTIO_F_REAL_DEVICE has been negotiated, a driver MUST NOT
+assume the device is implemented in software and runs on host CPU.
\devicenormative{\section}{Reserved Feature Bits}{Reserved Feature Bits}
@@ -5400,7 +5398,7 @@ accepted.
If VIRTIO_F_IN_ORDER has been negotiated, a device MUST use
buffers in the same order in which they have been available.
-A device MAY fail to operate further if VIRTIO_F_IO_BARRIER
+A device MAY fail to operate further if VIRTIO_F_REAL_DEVICE
is not accepted.
A device SHOULD offer VIRTIO_F_SR_IOV if it is a PCI device
--
2.17.0
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
next reply other threads:[~2018-06-25 12:25 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-25 12:24 Tiwei Bie [this message]
2018-06-25 16:07 ` [virtio-dev] [RFC] content: tweak VIRTIO_F_IO_BARRIER Halil Pasic
2018-06-25 17:42 ` Michael S. Tsirkin
2018-06-25 18:40 ` Halil Pasic
2018-06-25 21:27 ` Michael S. Tsirkin
2018-06-26 13:48 ` Halil Pasic
2018-06-25 19:19 ` [virtio-dev] " Michael S. Tsirkin
2018-06-26 13:47 ` Halil Pasic
2018-06-26 18:19 ` Tiwei Bie
2018-06-26 18:39 ` Michael S. Tsirkin
2018-06-27 16:08 ` Cornelia Huck
2018-06-28 8:52 ` Tiwei Bie
2018-06-28 12:56 ` Jason Wang
2018-06-29 4:21 ` Michael S. Tsirkin
2018-06-29 6:11 ` Jason Wang
2018-06-29 4:20 ` Michael S. Tsirkin
2018-07-16 11:04 ` Tiwei Bie
2018-08-27 18:36 ` Michael S. Tsirkin
2018-07-01 3:23 ` 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=20180625122442.22432-1-tiwei.bie@intel.com \
--to=tiwei.bie@intel.com \
--cc=cohuck@redhat.com \
--cc=cunming.liang@intel.com \
--cc=dan.daly@intel.com \
--cc=jasowang@redhat.com \
--cc=mst@redhat.com \
--cc=pasic@linux.vnet.ibm.com \
--cc=pbonzini@redhat.com \
--cc=stefanha@redhat.com \
--cc=virtio-dev@lists.oasis-open.org \
--cc=zhihong.wang@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox