netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jason Wang <jasowang@redhat.com>
To: Yongji Xie <xieyongji@bytedance.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Stefano Garzarella <sgarzare@redhat.com>,
	Parav Pandit <parav@nvidia.com>, Bob Liu <bob.liu@oracle.com>,
	Christoph Hellwig <hch@infradead.org>,
	Randy Dunlap <rdunlap@infradead.org>,
	Matthew Wilcox <willy@infradead.org>,
	viro@zeniv.linux.org.uk, Jens Axboe <axboe@kernel.dk>,
	bcrl@kvack.org, Jonathan Corbet <corbet@lwn.net>,
	virtualization@lists.linux-foundation.org,
	netdev@vger.kernel.org, kvm@vger.kernel.org, linux-aio@kvack.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [RFC v4 10/11] vduse: Introduce a workqueue for irq injection
Date: Fri, 5 Mar 2021 15:36:52 +0800	[thread overview]
Message-ID: <b01d9ee7-b038-cef2-8996-cd6401003267@redhat.com> (raw)
In-Reply-To: <CACycT3ug30sQptdoSP8XzRJVN7Yb2DPLBtfG-RNbus3BOhdONA@mail.gmail.com>


On 2021/3/5 3:27 下午, Yongji Xie wrote:
> On Fri, Mar 5, 2021 at 3:01 PM Jason Wang <jasowang@redhat.com> wrote:
>>
>> On 2021/3/5 2:36 下午, Yongji Xie wrote:
>>> On Fri, Mar 5, 2021 at 11:42 AM Jason Wang <jasowang@redhat.com> wrote:
>>>> On 2021/3/5 11:30 上午, Yongji Xie wrote:
>>>>> On Fri, Mar 5, 2021 at 11:05 AM Jason Wang <jasowang@redhat.com> wrote:
>>>>>> On 2021/3/4 4:58 下午, Yongji Xie wrote:
>>>>>>> On Thu, Mar 4, 2021 at 2:59 PM Jason Wang <jasowang@redhat.com> wrote:
>>>>>>>> On 2021/2/23 7:50 下午, Xie Yongji wrote:
>>>>>>>>> This patch introduces a workqueue to support injecting
>>>>>>>>> virtqueue's interrupt asynchronously. This is mainly
>>>>>>>>> for performance considerations which makes sure the push()
>>>>>>>>> and pop() for used vring can be asynchronous.
>>>>>>>> Do you have pref numbers for this patch?
>>>>>>>>
>>>>>>> No, I can do some tests for it if needed.
>>>>>>>
>>>>>>> Another problem is the VIRTIO_RING_F_EVENT_IDX feature will be useless
>>>>>>> if we call irq callback in ioctl context. Something like:
>>>>>>>
>>>>>>> virtqueue_push();
>>>>>>> virtio_notify();
>>>>>>>         ioctl()
>>>>>>> -------------------------------------------------
>>>>>>>             irq_cb()
>>>>>>>                 virtqueue_get_buf()
>>>>>>>
>>>>>>> The used vring is always empty each time we call virtqueue_push() in
>>>>>>> userspace. Not sure if it is what we expected.
>>>>>> I'm not sure I get the issue.
>>>>>>
>>>>>> THe used ring should be filled by virtqueue_push() which is done by
>>>>>> userspace before?
>>>>>>
>>>>> After userspace call virtqueue_push(), it always call virtio_notify()
>>>>> immediately. In traditional VM (vhost-vdpa) cases, virtio_notify()
>>>>> will inject an irq to VM and return, then vcpu thread will call
>>>>> interrupt handler. But in container (virtio-vdpa) cases,
>>>>> virtio_notify() will call interrupt handler directly. So it looks like
>>>>> we have to optimize the virtio-vdpa cases. But one problem is we don't
>>>>> know whether we are in the VM user case or container user case.
>>>> Yes, but I still don't get why used ring is empty after the ioctl()?
>>>> Used ring does not use bounce page so it should be visible to the kernel
>>>> driver. What did I miss :) ?
>>>>
>>> Sorry, I'm not saying the kernel can't see the correct used vring. I
>>> mean the kernel will consume the used vring in the ioctl context
>>> directly in the virtio-vdpa case. In userspace's view, that means
>>> virtqueue_push() is used vring's producer and virtio_notify() is used
>>> vring's consumer. They will be called one by one in one thread rather
>>> than different threads, which looks odd and has a bad effect on
>>> performance.
>>
>> Yes, that's why we need a workqueue (WQ_UNBOUND you used). Or do you
>> want to squash this patch into patch 8?
>>
>> So I think we can see obvious difference when virtio-vdpa is used.
>>
> But it looks like we don't need this workqueue in vhost-vdpa cases.
> Any suggestions?


I haven't had a deep thought. But I feel we can solve this by using the 
irq bypass manager (or something similar). Then we don't need it to be 
relayed via workqueue and vdpa. But I'm not sure how hard it will be.

Do you see any obvious performance regression by using the workqueue? Or 
we can optimize it in the future.

Thanks


>
> Thanks,
> Yongji
>


  reply	other threads:[~2021-03-05  7:37 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-23 11:50 [RFC v4 00/11] Introduce VDUSE - vDPA Device in Userspace Xie Yongji
2021-02-23 11:50 ` [RFC v4 01/11] eventfd: Increase the recursion depth of eventfd_signal() Xie Yongji
2021-03-02  6:44   ` Jason Wang
2021-03-02 10:32     ` Yongji Xie
2021-02-23 11:50 ` [RFC v4 02/11] vhost-vdpa: protect concurrent access to vhost device iotlb Xie Yongji
2021-03-02  6:47   ` Jason Wang
2021-03-02 10:20     ` Yongji Xie
2021-02-23 11:50 ` [RFC v4 03/11] vhost-iotlb: Add an opaque pointer for vhost IOTLB Xie Yongji
2021-03-02  6:49   ` Jason Wang
2021-02-23 11:50 ` [RFC v4 04/11] vdpa: Add an opaque pointer for vdpa_config_ops.dma_map() Xie Yongji
2021-03-02  6:50   ` Jason Wang
2021-02-23 11:50 ` [RFC v4 05/11] vdpa: Support transferring virtual addressing during DMA mapping Xie Yongji
2021-03-03 10:52   ` Mika Penttilä
2021-03-03 12:45     ` Yongji Xie
2021-03-03 13:38       ` Mika Penttilä
2021-03-04  3:07   ` Jason Wang
2021-03-04  5:40     ` Yongji Xie
2021-02-23 11:50 ` [RFC v4 06/11] vduse: Implement an MMU-based IOMMU driver Xie Yongji
2021-03-04  4:20   ` Jason Wang
2021-03-04  5:12     ` Yongji Xie
2021-03-05  3:35       ` Jason Wang
2021-03-05  6:15         ` Yongji Xie
     [not found]           ` <4db35f8c-ee3a-90fb-8d14-5d6014b4f6fa@redhat.com>
2021-03-05  7:13             ` Yongji Xie
2021-03-05  7:27               ` Jason Wang
2021-03-05  7:59                 ` Yongji Xie
2021-03-08  3:17                   ` Jason Wang
2021-03-08  3:45                     ` Yongji Xie
2021-03-08  3:52                       ` Jason Wang
2021-03-08  5:05                         ` Yongji Xie
2021-03-08  7:04                           ` Jason Wang
2021-03-08  7:08                             ` Yongji Xie
2021-02-23 11:50 ` [RFC v4 07/11] vduse: Introduce VDUSE - vDPA Device in Userspace Xie Yongji
2021-03-04  6:27   ` Jason Wang
2021-03-04  8:05     ` Yongji Xie
2021-03-05  3:20       ` Jason Wang
2021-03-05  3:49         ` Yongji Xie
2021-03-10 12:58   ` Jason Wang
2021-03-11  2:28     ` Yongji Xie
2021-02-23 11:50 ` [RFC v4 08/11] vduse: Add config interrupt support Xie Yongji
2021-02-23 11:50 ` [RFC v4 09/11] Documentation: Add documentation for VDUSE Xie Yongji
2021-03-04  6:39   ` Jason Wang
2021-03-04 10:35     ` Yongji Xie
2021-02-23 11:50 ` [RFC v4 10/11] vduse: Introduce a workqueue for irq injection Xie Yongji
2021-03-04  6:59   ` Jason Wang
2021-03-04  8:58     ` Yongji Xie
2021-03-05  3:04       ` Jason Wang
2021-03-05  3:30         ` Yongji Xie
2021-03-05  3:42           ` Jason Wang
2021-03-05  6:36             ` Yongji Xie
2021-03-05  7:01               ` Jason Wang
2021-03-05  7:27                 ` Yongji Xie
2021-03-05  7:36                   ` Jason Wang [this message]
2021-03-05  8:12                     ` Yongji Xie
2021-03-08  3:04                       ` Jason Wang
2021-03-08  4:50                         ` Yongji Xie
2021-03-08  7:01                           ` Jason Wang
2021-03-08  7:16                             ` Yongji Xie
2021-03-08  7:29                               ` Jason Wang
2021-02-23 11:50 ` [RFC v4 11/11] vduse: Support binding irq to the specified cpu Xie Yongji
2021-03-04  7:30   ` Jason Wang
2021-03-04  8:19     ` Yongji Xie
2021-03-05  3:11       ` Jason Wang
2021-03-05  3:37         ` Yongji Xie
2021-03-05  3:44           ` Jason Wang
2021-03-05  6:40             ` Yongji Xie

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=b01d9ee7-b038-cef2-8996-cd6401003267@redhat.com \
    --to=jasowang@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=bcrl@kvack.org \
    --cc=bob.liu@oracle.com \
    --cc=corbet@lwn.net \
    --cc=hch@infradead.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-aio@kvack.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=parav@nvidia.com \
    --cc=rdunlap@infradead.org \
    --cc=sgarzare@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=willy@infradead.org \
    --cc=xieyongji@bytedance.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).