From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Zhu, Lingshan" <lingshan.zhu@intel.com>
Cc: Jason Wang <jasowang@redhat.com>,
alex.williamson@redhat.com, pbonzini@redhat.com,
sean.j.christopherson@intel.com, wanpengli@tencent.com,
virtualization@lists.linux-foundation.org, kvm@vger.kernel.org,
netdev@vger.kernel.org, dan.daly@intel.com
Subject: Re: [PATCH 0/7] *** IRQ offloading for vDPA ***
Date: Thu, 16 Jul 2020 02:13:00 -0400 [thread overview]
Message-ID: <20200716021111-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <97032c51-3265-c94a-9ce1-f42fcc6d3075@intel.com>
On Thu, Jul 16, 2020 at 09:39:17AM +0800, Zhu, Lingshan wrote:
>
> On 7/15/2020 9:43 PM, Jason Wang wrote:
>
>
> On 2020/7/12 下午10:52, Zhu Lingshan wrote:
>
> Hi All,
>
> This series intends to implement IRQ offloading for
> vhost_vdpa.
>
> By the feat of irq forwarding facilities like posted
> interrupt on X86, irq bypass can help deliver
> interrupts to vCPU directly.
>
> vDPA devices have dedicated hardware backends like VFIO
> pass-throughed devices. So it would be possible to setup
> irq offloading(irq bypass) for vDPA devices and gain
> performance improvements.
>
> In my testing, with this feature, we can save 0.1ms
> in a ping between two VFs on average.
>
>
>
> Hi Lingshan:
>
> During the virtio-networking meeting, Michael spots two possible issues:
>
> 1) do we need an new uAPI to stop the irq offloading?
> 2) can interrupt lost during the eventfd ctx?
>
> For 1) I think we probably not, we can allocate an independent eventfd
> which does not map to MSIX. So the consumer can't match the producer and we
> fallback to eventfd based irq.
>
> Hi Jason,
>
> I wonder why we need to stop irq offloading, but if we need to do so, maybe a new uAPI would be more intuitive to me,
> but why and who(user? qemu?) shall initialize this process, based on what kinda of basis to make the decision?
>
> For 2) it looks to me guest should deal with the irq synchronization when
> mask or unmask MSIX vectors.
>
> Agreed!
Well we need to make sure during a switch each interrupt is reported
*somewhere*: either irq or eventfd - and not lost.
> Thanks,
> BR
> Zhu Lingshan
>
>
> What's your thought?
>
> Thanks
>
>
>
>
>
> Zhu Lingshan (7):
> vhost: introduce vhost_call_ctx
> kvm/vfio: detect assigned device via irqbypass manager
> vhost_vdpa: implement IRQ offloading functions in vhost_vdpa
> vDPA: implement IRQ offloading helpers in vDPA core
> virtio_vdpa: init IRQ offloading function pointers to NULL.
> ifcvf: replace irq_request/free with helpers in vDPA core.
> irqbypass: do not start consumer or producer when failed to connect
>
> arch/x86/kvm/x86.c | 10 ++++--
> drivers/vdpa/ifcvf/ifcvf_main.c | 11 +++---
> drivers/vdpa/vdpa.c | 46 +++++++++++++++++++++++++
> drivers/vhost/Kconfig | 1 +
> drivers/vhost/vdpa.c | 75
> +++++++++++++++++++++++++++++++++++++++--
> drivers/vhost/vhost.c | 22 ++++++++----
> drivers/vhost/vhost.h | 9 ++++-
> drivers/virtio/virtio_vdpa.c | 2 ++
> include/linux/vdpa.h | 11 ++++++
> virt/kvm/vfio.c | 2 --
> virt/lib/irqbypass.c | 16 +++++----
> 11 files changed, 181 insertions(+), 24 deletions(-)
>
>
>
>
prev parent reply other threads:[~2020-07-16 6:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-12 14:52 [PATCH 0/7] *** IRQ offloading for vDPA *** Zhu Lingshan
2020-07-15 13:43 ` Jason Wang
[not found] ` <97032c51-3265-c94a-9ce1-f42fcc6d3075@intel.com>
2020-07-16 2:59 ` Jason Wang
[not found] ` <29ab6da8-ed8e-6b91-d658-f3d240543b29@intel.com>
[not found] ` <1e91d9dd-d787-beff-2c14-9c76ffc3b285@redhat.com>
[not found] ` <a319cba3-8b3d-8968-0fb7-48a1d34042bf@intel.com>
2020-07-16 4:20 ` Jason Wang
2020-07-16 6:15 ` Michael S. Tsirkin
2020-07-16 8:06 ` Jason Wang
2020-07-16 6:13 ` Michael S. Tsirkin [this message]
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=20200716021111-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=dan.daly@intel.com \
--cc=jasowang@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=lingshan.zhu@intel.com \
--cc=netdev@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=sean.j.christopherson@intel.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=wanpengli@tencent.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;
as well as URLs for NNTP newsgroup(s).