All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Halil Pasic <pasic@linux.vnet.ibm.com>
Cc: Cornelia Huck <cohuck@redhat.com>,
	virtio@lists.oasis-open.org, virtio-dev@lists.oasis-open.org
Subject: [virtio] Re: [virtio-dev] Re: [virtio] [PATCH v7 08/11] packed virtqueues: more efficient virtqueue layout
Date: Mon, 5 Feb 2018 16:33:19 +0200	[thread overview]
Message-ID: <20180205161419-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <180bf54b-4e40-8c24-2888-0ea102ddb772@linux.vnet.ibm.com>

On Mon, Feb 05, 2018 at 12:54:41PM +0100, Halil Pasic wrote:
> 
> 
> On 01/30/2018 02:50 PM, Cornelia Huck wrote:
> > On Tue, 23 Jan 2018 02:01:07 +0200
> > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > 
> >> Performance analysis of this is in my kvm forum 2016 presentation.  The
> >> idea is to have a r/w descriptor in a ring structure, replacing the used
> >> and available ring, index and descriptor buffer.
> >>
> >> This is also easier for devices to implement than the 1.0 layout.
> >> Several more enhancements will be necessary to actually make this
> >> efficient for devices to use.
> >>
> >> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> >> ---
> [..]
> > 
> >> +\subsubsection{Notifying The Device}\label{sec:Basic Facilities
> >> +of a Virtio Device / Packed Virtqueues / Supplying Buffers to The Device / Notifying The Device}
> >> +
> >> +The actual method of device notification is bus-specific, but generally
> >> +it can be expensive.  So the device MAY suppress such notifications if it
> >> +doesn't need them, using the Driver Event Suppression structure
> >> +as detailed in section \ref{sec:Basic
> >> +Facilities of a Virtio Device / Packed Virtqueues / Event
> >> +Suppression Structure Format}.
> >> +
> >> +The driver has to be careful to expose the new \field{flags}
> >> +value before checking if notifications are suppressed.
> > 
> > This is all I could find regarding notifications, and it leaves me
> > puzzled how notifications are actually supposed to work; especially,
> > where that driver notification structure is supposed to be relayed.
> > 
> > I'm obviously coming from a ccw perspective, but I don't think that pci
> > is all that different (well, hopefully).
> > 
> > Up to now, we notified for a certain virtqueue -- i.e., the device
> > driver notified the device that there is something to process for a
> > certain queue. ccw uses the virtqueue number in a gpr for a hypercall,
> > pci seems to use a write to the config space IIUC. With the packed
> > layout, we have more payload per notification. We should be able to put
> > it in the same gpr than the virtqueue for ccw (if needed, with some
> > compat magic, or with a new hypercall, which would be ugly but doable).
> > Not sure how this is supposed to work with pci.
> > 
> > Has there been any prototyping done to implement this in qemu + KVM?
> > I'm unsure how this will work with ioeventfds, which just trigger.
> > 
> 
> 
> I'm also interested in an answer to Connie's question regarding a QEMU +
> KVM prototype. IMHO we should definitively have at least a such an
> prototype (preferably a reasonable implementation) before voting about
> the changes envisioned by this series.

This is certainly not how we did it for v1.0, and not how
oasis process works generally. Implementations are required
to move to an oasis standard change. We are working on
a committee standard deliverables.

I don't yet plan to work on an implementation yet: it's a bit of a
chicked and egg problem. People are reluctant to work on what's not in
the spec. We can always make changes as long as there are no
implementations.

> [META]
> 
> Unfortunately I have skipped v6 altogether (that is not even lurker
> mode). I'm a bit overwhelmed. I'm also in doubt about how to articulate
> my feelings and opinions. Maybe I will wait for v8 with my comments. You
> seem to have received enough comments for v7 already.

It's been under review for a very long time and only s390 related
changes are planned so I hope to move to voting after v8.

> Anyway, I'm happy to see virtio version 1.1 is slowly materializing.
> 
> Regards,
> Halil

If people first wait for all *other* comments to be addressed,
then post their own, it will take months to merge anything.
so please do not do that.

If someone specific does not have time to review that's ok - one can
always abstain in a vote. Also, with main changes merged it will be
easier to tweak wording - people can just post small patches with
suggested wording.

-- 
MST

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 


  reply	other threads:[~2018-02-05 14:33 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-10  9:47 [virtio] [PATCH v6 0/5] packed ring layout spec Michael S. Tsirkin
2018-01-10  9:47 ` [virtio] [PATCH v6 1/5] content: move 1.0 queue format out to a separate section Michael S. Tsirkin
2018-01-10 12:45   ` Cornelia Huck
2018-01-10  9:47 ` [virtio] [PATCH v6 2/5] content: move ring text out to a separate file Michael S. Tsirkin
2018-01-10 12:46   ` Cornelia Huck
2018-01-10  9:47 ` [virtio] [PATCH v6 3/5] content: move virtqueue operation description Michael S. Tsirkin
2018-01-10 12:48   ` Cornelia Huck
2018-01-10  9:47 ` [virtio] [PATCH v6 4/5] packed virtqueues: more efficient virtqueue layout Michael S. Tsirkin
2018-01-10 10:47   ` Cornelia Huck
2018-01-10 13:49   ` [virtio-dev] " Jens Freimann
2018-01-10 14:39     ` [virtio] " Michael S. Tsirkin
2018-01-10 14:08   ` Tiwei Bie
2018-01-10 14:39     ` [virtio] " Michael S. Tsirkin
2018-01-10 14:15   ` [virtio] " Cornelia Huck
2018-01-10 15:37     ` Michael S. Tsirkin
2018-01-10  9:47 ` [virtio] [PATCH v6 5/5] packed-ring: add in order request support Michael S. Tsirkin
2018-01-10 10:33 ` [virtio] [PATCH v6 0/5] packed ring layout spec Cornelia Huck
2018-01-10 11:10   ` Michael S. Tsirkin
2018-01-10 11:14     ` Cornelia Huck
2018-01-10 11:16       ` Michael S. Tsirkin
2018-01-23  0:01 ` [virtio] [PATCH v7 02/11] content: move ring text out to a separate file Michael S. Tsirkin
2018-01-30 10:07   ` Cornelia Huck
2018-01-23  0:01 ` [virtio] [PATCH v7 01/11] content: move 1.0 queue format out to a separate section Michael S. Tsirkin
2018-01-30 10:06   ` Cornelia Huck
2018-02-05 22:54   ` Halil Pasic
2018-02-06  0:05     ` Michael S. Tsirkin
2018-02-06  8:38       ` Cornelia Huck
2018-02-06 11:10       ` [virtio] Re: [virtio-dev] " Halil Pasic
2018-02-06 11:20         ` Cornelia Huck
2018-02-06 12:03           ` Halil Pasic
2018-02-06 22:58         ` Michael S. Tsirkin
2018-01-23  0:01 ` [virtio] [PATCH v7 03/11] content: move virtqueue operation description Michael S. Tsirkin
2018-01-30 10:12   ` Cornelia Huck
2018-01-23  0:01 ` [virtio] [PATCH v7 04/11] content: replace mentions of len with used length Michael S. Tsirkin
2018-01-30 10:16   ` Cornelia Huck
2018-01-30 16:38     ` Michael S. Tsirkin
2018-01-23  0:01 ` [virtio] [PATCH v7 05/11] content: generalize transport ring part naming Michael S. Tsirkin
2018-01-30 10:27   ` Cornelia Huck
2018-01-23  0:01 ` [virtio] [PATCH v7 06/11] content: generalize rest of text Michael S. Tsirkin
2018-01-30 10:31   ` Cornelia Huck
2018-01-30 16:40     ` Michael S. Tsirkin
2018-01-23  0:01 ` [virtio] [PATCH v7 07/11] split-ring: generalize text Michael S. Tsirkin
2018-01-30 10:45   ` Cornelia Huck
2018-01-30 16:42     ` Michael S. Tsirkin
2018-01-23  0:01 ` [virtio] [PATCH v7 08/11] packed virtqueues: more efficient virtqueue layout Michael S. Tsirkin
2018-01-30  7:16   ` [virtio-dev] " Tiwei Bie
2018-01-30 16:45     ` [virtio] " Michael S. Tsirkin
2018-01-30 13:07   ` Jens Freimann
2018-01-30 13:50   ` [virtio] " Cornelia Huck
2018-01-30 19:40     ` Michael S. Tsirkin
2018-02-01  3:05       ` [virtio-dev] " Tiwei Bie
2018-02-01 10:11         ` [virtio] " Cornelia Huck
2018-02-01 14:43           ` Michael S. Tsirkin
2018-02-05 11:54     ` Halil Pasic
2018-02-05 14:33       ` Michael S. Tsirkin [this message]
2018-02-05 16:57         ` Halil Pasic
2018-02-05 17:00           ` Paolo Bonzini
2018-02-05 18:16             ` Cornelia Huck
2018-02-05 18:21               ` Michael S. Tsirkin
2018-02-05 18:26                 ` Cornelia Huck
2018-02-05 17:55           ` Michael S. Tsirkin
2018-02-05 22:57   ` [virtio] Re: [virtio-dev] " Halil Pasic
2018-01-23  0:01 ` [virtio] [PATCH v7 09/11] content: in-order buffer use Michael S. Tsirkin
2018-02-01 11:01   ` Cornelia Huck
2018-02-12 13:18   ` Stefan Hajnoczi
2018-01-23  0:01 ` [virtio] [PATCH v7 11/11] split-ring: in order feature Michael S. Tsirkin
2018-02-02 11:06   ` Cornelia Huck
2018-02-12 13:23   ` Stefan Hajnoczi
2018-01-23  0:01 ` [virtio] [PATCH v7 10/11] packed-ring: add in order support Michael S. Tsirkin
2018-02-02 11:03   ` Cornelia Huck
2018-02-12 13:22   ` Stefan Hajnoczi

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=20180205161419-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=pasic@linux.vnet.ibm.com \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=virtio@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.