All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Wang <wei.w.wang@intel.com>
To: Stefan Hajnoczi <stefanha@redhat.com>, Jason Wang <jasowang@redhat.com>
Cc: qemu-devel@nongnu.org, mst@redhat.com, zhiyong.yang@intel.com,
	Maxime Coquelin <maxime.coquelin@redhat.com>
Subject: Re: [Qemu-devel] [RFC 0/2] virtio-vhost-user: add virtio-vhost-user device
Date: Tue, 23 Jan 2018 18:46:18 +0800	[thread overview]
Message-ID: <5A67127A.5060600@intel.com> (raw)
In-Reply-To: <20180122121751.GD31621@stefanha-x1.localdomain>

On 01/22/2018 08:17 PM, Stefan Hajnoczi wrote:
> On Mon, Jan 22, 2018 at 11:33:46AM +0800, Jason Wang wrote:
>> On 2018年01月19日 21:06, Stefan Hajnoczi wrote:
>>
>> Probably not for the following cases:
>>
>> 1) kick/call
> I disagree here because kick/call is actually very efficient!
>
> VM1's irqfd is the ioeventfd for VM2.  When VM2 writes to the ioeventfd
> there is a single lightweight vmexit which injects an interrupt into
> VM1.  QEMU is not involved and the host kernel scheduler is not involved
> so this is a low-latency operation.
>
> I haven't tested this yet but the ioeventfd code looks like this will
> work.


This have been tested in vhost-pci v2 patches which worked with with a 
kernel driver. It worked pretty well.

>> Btw, it's better to have some early numbers, e.g what testpmd reports during
>> forwarding.
> I need to rely on others to do this (and many other things!) because
> virtio-vhost-user isn't the focus of my work.
>
> These patches were written to demonstrate my suggestions for vhost-pci.
> They were written at work but also on weekends, early mornings, and late
> nights to avoid delaying Wei and Zhiyong's vhost-pci work too much.
>
> If this approach has merit then I hope others will take over and I'll
> play a smaller role addressing some of the todo items and cleanups.

Thanks again for the great effort, your implementation looks nice.

If we finally decide to go with the virtio-vhost-user approach, I think 
zhiyong and I can help take over the work to continue, too.

I'm still thinking about solutions to the two issues that I shared 
yesterday - it should be like a normal PCI device, and if we unbind its 
driver, and bind back, it should also work.


Best,
Wei

  parent reply	other threads:[~2018-01-23 10:43 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-19 13:06 [Qemu-devel] [RFC 0/2] virtio-vhost-user: add virtio-vhost-user device Stefan Hajnoczi
2018-01-19 13:06 ` [Qemu-devel] [RFC 1/2] vhost-user: share the vhost-user protocol related structures Stefan Hajnoczi
2018-01-19 13:06 ` [Qemu-devel] [RFC 2/2] virtio-vhost-user: add virtio-vhost-user device Stefan Hajnoczi
2018-01-19 13:55 ` [Qemu-devel] [RFC 0/2] " Stefan Hajnoczi
2018-01-22  3:33 ` Jason Wang
2018-01-22 12:17   ` Stefan Hajnoczi
2018-01-22 20:04     ` Michael S. Tsirkin
2018-01-23 10:01       ` Jason Wang
2018-01-23 16:07         ` Michael S. Tsirkin
2018-01-25 14:07           ` Paolo Bonzini
2018-01-25 14:48             ` Michael S. Tsirkin
2018-01-26  3:49               ` Jason Wang
2018-01-23 10:09       ` Stefan Hajnoczi
2018-01-23 10:46     ` Wei Wang [this message]
2018-01-22 11:09 ` Wei Wang
2018-01-23 11:12   ` Stefan Hajnoczi
2018-01-23 13:06     ` Wei Wang
2018-01-24 11:40       ` Stefan Hajnoczi
2018-01-25 10:19         ` Wei Wang
2018-01-26 14:44           ` Stefan Hajnoczi
2018-01-30 12:09             ` Wei Wang
2018-02-01 17:08               ` Michael S. Tsirkin
2018-02-02 13:08                 ` Wei Wang
2018-02-05 16:25                   ` Stefan Hajnoczi
2018-02-06  1:28                     ` Wang, Wei W
2018-02-06  9:31                       ` Stefan Hajnoczi
2018-02-06 12:42                         ` Wang, Wei W
2018-02-06 14:13                           ` Stefan Hajnoczi
2018-02-02 15:25               ` Stefan Hajnoczi
2018-02-05  9:57                 ` Wang, Wei W
2018-02-05 15:57                   ` 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=5A67127A.5060600@intel.com \
    --to=wei.w.wang@intel.com \
    --cc=jasowang@redhat.com \
    --cc=maxime.coquelin@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=zhiyong.yang@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 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.