qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Cornelia Huck <cornelia.huck@de.ibm.com>
To: Jason Wang <jasowang@redhat.com>
Cc: mst@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] vhost: don't set vring call if no vector
Date: Mon, 1 Aug 2016 20:00:29 +0200	[thread overview]
Message-ID: <20160801200029.30da2f30.cornelia.huck@de.ibm.com> (raw)
In-Reply-To: <1470038878-5599-1-git-send-email-jasowang@redhat.com>

On Mon,  1 Aug 2016 16:07:58 +0800
Jason Wang <jasowang@redhat.com> wrote:

> We used to set vring call fd unconditionally even if guest driver does
> not use MSIX for this vritqueue at all. This will cause lots of
> unnecessary userspace access and other checks for drivers does not use
> interrupt at all (e.g virtio-net pmd). So check and clean vring call
> fd if guest does not use any vector for this virtqueue at
> all.

So the basic idea is: don't setup signalling via eventfd if the guest
did not enable interrupts for this queue, right?

> 
> Perf diffs (on rx) shows lots of cpus wasted on vhost_signal() were saved:
> 
> #
>     28.12%  -27.82%  [vhost]           [k] vhost_signal
>     14.44%   -1.69%  [kernel.vmlinux]  [k] copy_user_generic_string
>      7.05%   +1.53%  [kernel.vmlinux]  [k] __free_page_frag
>      6.51%   +5.53%  [vhost]           [k] vhost_get_vq_desc
> ...
> 
> Pktgen tests shows 15.8% improvement on rx pps and 6.5% on tx pps.
> 
> Before: RX 2.08Mpps TX 1.35Mpps
> After:  RX 2.41Mpps TX 1.44Mpps
> 
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
>  hw/virtio/vhost.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c
> index 3d0c807..bd051ab 100644
> --- a/hw/virtio/vhost.c
> +++ b/hw/virtio/vhost.c
> @@ -822,6 +822,9 @@ static int vhost_virtqueue_start(struct vhost_dev *dev,
>                                  struct vhost_virtqueue *vq,
>                                  unsigned idx)
>  {
> +    BusState *qbus = BUS(qdev_get_parent_bus(DEVICE(vdev)));
> +    VirtioBusState *vbus = VIRTIO_BUS(qbus);
> +    VirtioBusClass *k = VIRTIO_BUS_GET_CLASS(vbus);
>      hwaddr s, l, a;
>      int r;
>      int vhost_vq_index = dev->vhost_ops->vhost_get_vq_index(dev, idx);
> @@ -912,8 +915,19 @@ static int vhost_virtqueue_start(struct vhost_dev *dev,
>          vhost_virtqueue_mask(dev, vdev, idx, false);
>      }
> 
> +    if (k->query_guest_notifiers &&
> +        k->query_guest_notifiers(qbus->parent) &&
> +        virtio_queue_vector(vdev, idx) == VIRTIO_NO_VECTOR) {

I'm trying to imagine what this means for virtio-ccw. Keep in mind that
we don't have the concept of setting a 'vector' by the OS (the vector
is setup internally to the queue index and the OS does not see it.)

->query_guest_notifiers() is true if the OS has enabled the subchannel
of the proxy device (i.e., if it is enabled for doing *anything* with
the subchannel, regardless whether the OS wants to be notified or is
planning to poll.) The second condition will never hold true for any
valid queue once the OS has setup the queues.

So this won't break anything for virtio-ccw AFAICS, but I don't think
we gain anything.

> +        file.fd = -1;
> +        r = dev->vhost_ops->vhost_set_vring_call(dev, &file);
> +        if (r) {
> +            goto fail_vector;
> +        }
> +    }
> +
>      return 0;
> 
> +fail_vector:
>  fail_kick:
>  fail_alloc:
>      cpu_physical_memory_unmap(vq->ring, virtio_queue_get_ring_size(vdev, idx),

  parent reply	other threads:[~2016-08-01 18:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-01  8:07 [Qemu-devel] [PATCH] vhost: don't set vring call if no vector Jason Wang
2016-08-01 14:08 ` Michael S. Tsirkin
2016-08-02  2:37   ` Jason Wang
2016-08-01 18:00 ` Cornelia Huck [this message]
2016-08-02  2:39   ` Jason Wang
2016-08-02  6:37     ` Cornelia Huck
2016-08-03  1:48       ` Jason Wang

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=20160801200029.30da2f30.cornelia.huck@de.ibm.com \
    --to=cornelia.huck@de.ibm.com \
    --cc=jasowang@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).