From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 911B0C6FD1D for ; Thu, 30 Mar 2023 06:11:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230140AbjC3GLm (ORCPT ); Thu, 30 Mar 2023 02:11:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38248 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229505AbjC3GLj (ORCPT ); Thu, 30 Mar 2023 02:11:39 -0400 Received: from out30-119.freemail.mail.aliyun.com (out30-119.freemail.mail.aliyun.com [115.124.30.119]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DA6CA40CF; Wed, 29 Mar 2023 23:11:37 -0700 (PDT) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R461e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046056;MF=xuanzhuo@linux.alibaba.com;NM=1;PH=DS;RN=8;SR=0;TI=SMTPD_---0VezJ716_1680156693; Received: from localhost(mailfrom:xuanzhuo@linux.alibaba.com fp:SMTPD_---0VezJ716_1680156693) by smtp.aliyun-inc.com; Thu, 30 Mar 2023 14:11:34 +0800 Message-ID: <1680156457.5551112-5-xuanzhuo@linux.alibaba.com> Subject: Re: [PATCH v3 3/4] virtio: fix up virtio_disable_cb Date: Thu, 30 Mar 2023 14:07:37 +0800 From: Xuan Zhuo To: "Michael S. Tsirkin" Cc: Willem de Bruijn , netdev@vger.kernel.org, virtualization@lists.linux-foundation.org, Jakub Kicinski , Wei Wang , David Miller , linux-kernel@vger.kernel.org References: <20210526082423.47837-1-mst@redhat.com> <20210526082423.47837-4-mst@redhat.com> In-Reply-To: <20210526082423.47837-4-mst@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 26 May 2021 04:24:40 -0400, "Michael S. Tsirkin" wrote: > virtio_disable_cb is currently a nop for split ring with event index. > This is because it used to be always called from a callback when we know > device won't trigger more events until we update the index. However, > now that we run with interrupts enabled a lot we also poll without a > callback so that is different: disabling callbacks will help reduce the > number of spurious interrupts. > Further, if using event index with a packed ring, and if being called > from a callback, we actually do disable interrupts which is unnecessary. > > Fix both issues by tracking whenever we get a callback. If that is > the case disabling interrupts with event index can be a nop. > If not the case disable interrupts. Note: with a split ring > there's no explicit "no interrupts" value. For now we write > a fixed value so our chance of triggering an interupt > is 1/ring size. It's probably better to write something > related to the last used index there to reduce the chance > even further. For now I'm keeping it simple. Don't understand, is this patch necessary? For this patch set, we can do without this patch. So doest this patch optimize virtqueue_disable_cb() by reducing a modification of vring_used_event(&vq-> split.vring)? Or I miss something. Thanks. > > Signed-off-by: Michael S. Tsirkin > --- > drivers/virtio/virtio_ring.c | 26 +++++++++++++++++++++++++- > 1 file changed, 25 insertions(+), 1 deletion(-) > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > index 71e16b53e9c1..88f0b16b11b8 100644 > --- a/drivers/virtio/virtio_ring.c > +++ b/drivers/virtio/virtio_ring.c > @@ -113,6 +113,9 @@ struct vring_virtqueue { > /* Last used index we've seen. */ > u16 last_used_idx; > > + /* Hint for event idx: already triggered no need to disable. */ > + bool event_triggered; > + > union { > /* Available for split ring */ > struct { > @@ -739,7 +742,10 @@ static void virtqueue_disable_cb_split(struct virtqueue *_vq) > > if (!(vq->split.avail_flags_shadow & VRING_AVAIL_F_NO_INTERRUPT)) { > vq->split.avail_flags_shadow |= VRING_AVAIL_F_NO_INTERRUPT; > - if (!vq->event) > + if (vq->event) > + /* TODO: this is a hack. Figure out a cleaner value to write. */ > + vring_used_event(&vq->split.vring) = 0x0; > + else > vq->split.vring.avail->flags = > cpu_to_virtio16(_vq->vdev, > vq->split.avail_flags_shadow); > @@ -1605,6 +1611,7 @@ static struct virtqueue *vring_create_virtqueue_packed( > vq->weak_barriers = weak_barriers; > vq->broken = false; > vq->last_used_idx = 0; > + vq->event_triggered = false; > vq->num_added = 0; > vq->packed_ring = true; > vq->use_dma_api = vring_use_dma_api(vdev); > @@ -1919,6 +1926,12 @@ void virtqueue_disable_cb(struct virtqueue *_vq) > { > struct vring_virtqueue *vq = to_vvq(_vq); > > + /* If device triggered an event already it won't trigger one again: > + * no need to disable. > + */ > + if (vq->event_triggered) > + return; > + > if (vq->packed_ring) > virtqueue_disable_cb_packed(_vq); > else > @@ -1942,6 +1955,9 @@ unsigned virtqueue_enable_cb_prepare(struct virtqueue *_vq) > { > struct vring_virtqueue *vq = to_vvq(_vq); > > + if (vq->event_triggered) > + vq->event_triggered = false; > + > return vq->packed_ring ? virtqueue_enable_cb_prepare_packed(_vq) : > virtqueue_enable_cb_prepare_split(_vq); > } > @@ -2005,6 +2021,9 @@ bool virtqueue_enable_cb_delayed(struct virtqueue *_vq) > { > struct vring_virtqueue *vq = to_vvq(_vq); > > + if (vq->event_triggered) > + vq->event_triggered = false; > + > return vq->packed_ring ? virtqueue_enable_cb_delayed_packed(_vq) : > virtqueue_enable_cb_delayed_split(_vq); > } > @@ -2044,6 +2063,10 @@ irqreturn_t vring_interrupt(int irq, void *_vq) > if (unlikely(vq->broken)) > return IRQ_HANDLED; > > + /* Just a hint for performance: so it's ok that this can be racy! */ > + if (vq->event) > + vq->event_triggered = true; > + > pr_debug("virtqueue callback for %p (%p)\n", vq, vq->vq.callback); > if (vq->vq.callback) > vq->vq.callback(&vq->vq); > @@ -2083,6 +2106,7 @@ struct virtqueue *__vring_new_virtqueue(unsigned int index, > vq->weak_barriers = weak_barriers; > vq->broken = false; > vq->last_used_idx = 0; > + vq->event_triggered = false; > vq->num_added = 0; > vq->use_dma_api = vring_use_dma_api(vdev); > #ifdef DEBUG > -- > MST > > _______________________________________________ > Virtualization mailing list > Virtualization@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/virtualization