Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp691817rwl; Fri, 24 Mar 2023 00:08:51 -0700 (PDT) X-Google-Smtp-Source: AK7set84fEzmWUHnf1yrSZnfXG9fFKwETBjNbiNNjm+QoIVtgixvKBIhSpa6ose0ZfKpYGj5r39E X-Received: by 2002:a05:6a20:4f9e:b0:d4:32bb:11bd with SMTP id gh30-20020a056a204f9e00b000d432bb11bdmr1483995pzb.45.1679641731509; Fri, 24 Mar 2023 00:08:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679641731; cv=none; d=google.com; s=arc-20160816; b=wjbt9ehowKcy5aBNDfN4rHQXHoIuaupBNPY4nrBuXWdK6+xwRzJLKV+eGjKXE39FeG E/pD+4tQz2tS9EMHB96zlaEwDxIFDkiLKqdHO1kho4p0k0EVjNsJoXFYDD/Fbfb4gEp+ wITk31unLp8y3zG4Bkm5JFP6/PfZ+52j1QWt3dms3DLHlvRsQocikgJG2nQHgaXQ6xQ9 iLRO1OTJ3HWaAXqK2wr2Z2u/NlwXFknonzb0Ug7v4g6JqDfXMkkCzH/m+hpMvUxxN/ze 3mv9/CIBvbEMTH6Uhp912GaGSiin46AgfQ4xB8FFt1DyxY1ld1IDArzL+X6L3A3HDJjF HFEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=GQ7MkMIkN7lvSOZvIITGhL1ZHsdpsx64jjjlRFP63dg=; b=A3yUgInUwHyHuQRuE26caVP+IuSG1MpPCZIQutCCN8fdGFuLyDAhsqmkcF9pFMIQTz zvoouqJlGckbacXsGkBewFogACf2Yp0yAM65XKV2419HRBqJoIvVGdojIOsiSaAbxnYp WlQx8jibVIlSKjuaRXjsG0kDnskphRPl1pYnM/lqF3PheJF1YBPBxXBK2rLVEx6HePNi FLfDZi10EZNGWY0oVh3M9gv3FOSNPyY6WnOiZrex0e+yvUfjoaKVukAvdxK3XJ0Q7Sfo PHKpMa3WAQPnghzSFGIAaBWy+7xB1N9Nv2mLrG6R0U5k2dpLiy416dsZCdVBezvmOk/z Di7w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=NgzGk64e; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v7-20020a63f207000000b0050fb3fdeecdsi8158433pgh.177.2023.03.24.00.08.40; Fri, 24 Mar 2023 00:08:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=NgzGk64e; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229938AbjCXHBH (ORCPT + 99 others); Fri, 24 Mar 2023 03:01:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44394 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229536AbjCXHBF (ORCPT ); Fri, 24 Mar 2023 03:01:05 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 373B324BC8 for ; Fri, 24 Mar 2023 00:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1679641214; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GQ7MkMIkN7lvSOZvIITGhL1ZHsdpsx64jjjlRFP63dg=; b=NgzGk64eE8FbF1Wlrf4+WF0SvGTPYe8PCAX6hYJUPCxQljdVjFBNoyuLqnEHAnPDzisVb8 BSGW4WrGSFcjop3nCeYwZvrV75J3xxQ3gq/aIWNk1g9koo0tppM6sWRYNDKYFfKfpsmVT/ oiHp91lm7IsQHvRvgV7DHrApa2g9U8s= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-423-GBONZXsePByYykXQ_UtT4A-1; Fri, 24 Mar 2023 03:00:12 -0400 X-MC-Unique: GBONZXsePByYykXQ_UtT4A-1 Received: by mail-wm1-f69.google.com with SMTP id o37-20020a05600c512500b003edd119ec9eso593751wms.0 for ; Fri, 24 Mar 2023 00:00:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679641212; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=GQ7MkMIkN7lvSOZvIITGhL1ZHsdpsx64jjjlRFP63dg=; b=Baq4/mDr0iKnxcswIOvugOG+9y5Y7d4Y9b+Tj+ghO/xw5d0nY2y8NCBW8qoYV2z5p+ M9oVdG4OGkDEGypw/uiKgSgVV1UTxVtkGipqmIL55P1Cgd4kmCgbkynmMQj9+oTiwbfp mREu/qPzPpciKn5TyWScuFmmeQFGwACC9U8wfEOxcVzBQ5if4nPrhVI3Y6MVHSHpyS+B 0fkMTG1IF52o5my1OT9/9Brf+d49r/ocD+qAXKsdNxmYuSRnn169VRp4DwiAbV6nOPt2 Lh5R1iqqfN+nj9bI51Ycldiy+H608DTKuEK8rmFQ77IyQxxBHGH4ZbCSnAH/M/c3ey+/ 2p3Q== X-Gm-Message-State: AO0yUKUwuuqgSq4DZf6f1gsKcxSNqEhYp/DbYDv8Zktd485tOAZgBu+i EBdNNfp0IQpnS4l+h5UkGlz7GuzIukdVC7WXes1PuAgwZlbg0gwpoY9HC423jphznzCVlMVeBzD e0p4fbqOf9wyF22bptz06lwZg X-Received: by 2002:a05:600c:2199:b0:3ee:a492:e973 with SMTP id e25-20020a05600c219900b003eea492e973mr1486270wme.28.1679641211758; Fri, 24 Mar 2023 00:00:11 -0700 (PDT) X-Received: by 2002:a05:600c:2199:b0:3ee:a492:e973 with SMTP id e25-20020a05600c219900b003eea492e973mr1486251wme.28.1679641211353; Fri, 24 Mar 2023 00:00:11 -0700 (PDT) Received: from redhat.com ([2.52.12.190]) by smtp.gmail.com with ESMTPSA id w13-20020a1cf60d000000b003ed4f6c6234sm3985904wmc.23.2023.03.24.00.00.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Mar 2023 00:00:10 -0700 (PDT) Date: Fri, 24 Mar 2023 03:00:08 -0400 From: "Michael S. Tsirkin" To: Jason Wang Cc: =?utf-8?B?6buE5p2w?= , "open list:VIRTIO CORE AND NET DRIVERS" , open list Subject: Re: [External] Re: [PATCH] virtio_ring: Suppress tx interrupt when napi_tx disable Message-ID: <20230324025937-mutt-send-email-mst@kernel.org> References: <20230321085953.24949-1-huangjie.albert@bytedance.com> <20230324013805-mutt-send-email-mst@kernel.org> <20230324024155-mutt-send-email-mst@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=1.5 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,URIBL_BLACK autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 24, 2023 at 02:47:02PM +0800, Jason Wang wrote: > On Fri, Mar 24, 2023 at 2:42 PM Michael S. Tsirkin wrote: > > > > On Fri, Mar 24, 2023 at 02:32:40PM +0800, Jason Wang wrote: > > > On Fri, Mar 24, 2023 at 1:59 PM Michael S. Tsirkin wrote: > > > > > > > > On Fri, Mar 24, 2023 at 11:41:12AM +0800, Jason Wang wrote: > > > > > On Thu, Mar 23, 2023 at 4:01 PM 黄杰 wrote: > > > > > > > > > > > > Jason Wang 于2023年3月22日周三 10:37写道: > > > > > > > > > > > > > > On Tue, Mar 21, 2023 at 5:00 PM Albert Huang > > > > > > > wrote: > > > > > > > > > > > > > > > > From: "huangjie.albert" > > > > > > > > > > > > > > > > fix commit 8d622d21d248 ("virtio: fix up virtio_disable_cb") > > > > > > > > > > > > > > > > if we disable the napi_tx. when we triger a tx interrupt, the > > > > > > > > > > > > > > typo should be "trigger" > > > > > > > > > > > > > > > > > > > OK, thanks for this. I will correct it in the next version > > > > > > > > > > > > > > vq->event_triggered will be set to true. It will no longer be > > > > > > > > set to false. Unless we explicitly call virtqueue_enable_cb_delayed > > > > > > > > or virtqueue_enable_cb_prepare > > > > > > > > > > > > > > > > if we disable the napi_tx, It will only be called when the tx ring > > > > > > > > buffer is relatively small: > > > > > > > > virtio_net->start_xmit: > > > > > > > > if (sq->vq->num_free < 2+MAX_SKB_FRAGS) { > > > > > > > > netif_stop_subqueue(dev, qnum); > > > > > > > > if (!use_napi && > > > > > > > > unlikely(!virtqueue_enable_cb_delayed(sq->vq))) { > > > > > > > > /* More just got used, free them then recheck. */ > > > > > > > > free_old_xmit_skbs(sq, false); > > > > > > > > if (sq->vq->num_free >= 2+MAX_SKB_FRAGS) { > > > > > > > > netif_start_subqueue(dev, qnum); > > > > > > > > virtqueue_disable_cb(sq->vq); > > > > > > > > } > > > > > > > > > > > > > > The code example here is out of date, make sure your tree has this: > > > > > > > > > > > > also, I will correct it in the next version,this is from kernel 5.15. > > > > > > > > > > > > > > > > > > > > commit d71ebe8114b4bf622804b810f5e274069060a174 > > > > > > > Author: Jason Wang > > > > > > > Date: Tue Jan 17 11:47:07 2023 +0800 > > > > > > > > > > > > > > virtio-net: correctly enable callback during start_xmit > > > > > > > > > > > > > > > } > > > > > > > > } > > > > > > > > Because event_triggered is true.Therefore, VRING_AVAIL_F_NO_INTERRUPT or > > > > > > > > VRING_PACKED_EVENT_FLAG_DISABLE will not be set.So we update > > > > > > > > vring_used_event(&vq->split.vring) or vq->packed.vring.driver->off_wrap > > > > > > > > every time we call virtqueue_get_buf_ctx.This will bring more interruptions. > > > > > > > > > > > > > > Can you please post how to test with the performance numbers? > > > > > > > > > > > > > > > > > > > iperf3 tcp stream: > > > > > > vm1 -----------------> vm2 > > > > > > vm2 just receive tcp data stream from vm1, and send the ack to vm1, > > > > > > there are so > > > > > > many tx interruptions in vm2. > > > > > > > > > > > > but without event_triggered there are just a few tx interruptions. > > > > > > > > > > > > > > > > > > > > > > if event_triggered is set to true, do not update vring_used_event(&vq->split.vring) > > > > > > > > or vq->packed.vring.driver->off_wrap > > > > > > > > > > > > > > > > Signed-off-by: huangjie.albert > > > > > > > > --- > > > > > > > > drivers/virtio/virtio_ring.c | 6 ++++-- > > > > > > > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > > > > > > > > > > > > > diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c > > > > > > > > index 307e139cb11d..f486cccadbeb 100644 > > > > > > > > --- a/drivers/virtio/virtio_ring.c > > > > > > > > +++ b/drivers/virtio/virtio_ring.c > > > > > > > > @@ -795,7 +795,8 @@ static void *virtqueue_get_buf_ctx_split(struct virtqueue *_vq, > > > > > > > > /* If we expect an interrupt for the next entry, tell host > > > > > > > > * by writing event index and flush out the write before > > > > > > > > * the read in the next get_buf call. */ > > > > > > > > - if (!(vq->split.avail_flags_shadow & VRING_AVAIL_F_NO_INTERRUPT)) > > > > > > > > + if (!(vq->split.avail_flags_shadow & VRING_AVAIL_F_NO_INTERRUPT) > > > > > > > > + && (vq->event_triggered == false)) > > > > > > > > > > > > > > I'm not sure this can work, when event_triggered is true it means > > > > > > > we've got an interrupt, in this case if we want another interrupt for > > > > > > > the next entry, we should update used_event otherwise we will lose > > > > > > > that interrupt? > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > Normally, if we receive an interrupt, we should disable the interrupt > > > > > > in the interrupt callback handler. > > > > > > > > > > So the problem is: > > > > > > > > > > 1) event_triggered was set to true in vring_interrupt() > > > > > > > > > > 2) after this nothing will happen for virtqueue_disable_cb() so > > > > > VRING_AVAIL_F_NO_INTERRUPT is not set in avail_flags_shadow > > > > > 3) virtqueue_get_buf_ctx_split() will still think the cb is enabled > > > > > then it tries to publish new event > > > > > > > > Oh. Good point! I think when I wrote up > > > > 8d622d21d248 ("virtio: fix up virtio_disable_cb") > > > > I missed this corner case. > > > > > > > > > > > > > > > > > This makes me think about whether or not we really need > > > > > event_triggered. The assumption in the virtqueue_disable_cb() seems > > > > > wrong: > > > > > > > > > > /* If device triggered an event already it won't trigger one again: > > > > > * no need to disable. > > > > > */ > > > > > if (vq->event_triggered) > > > > > return; > > > > > > > > > > This is wrong if there's no event index support. > > > > > > > > > > > > I don't get it. how does this get triggered? > > > > > > > > You are talking about device without event index? > > > > Here's code from vring_interrupt(): > > > > > > > > /* Just a hint for performance: so it's ok that this can be racy! */ > > > > if (vq->event) > > > > vq->event_triggered = true; > > > > > > But we have the following in virtqueue_disable_cb(): > > > > > > /* 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 > > > virtqueue_disable_cb_split(_vq); > > > > > > This means, without an event index, we don't set avail flags. So the > > > interrupt is not disabled actually in this case. > > > > > > Thanks > > > > Only if event_triggered is true, which without event index it never is. > > I'm not sure I will get here. I meant for example the commit > suppresses the effort of skb_xmit_done(): > > static void skb_xmit_done(struct virtqueue *vq) > { > struct virtnet_info *vi = vq->vdev->priv; > struct napi_struct *napi = &vi->sq[vq2txq(vq)].napi; > > /* Suppress further interrupts. */ > virtqueue_disable_cb(vq); > > The virtqueue_disable_cb() doesn't disable further interrupts when the > event index is not there. > > Thanks Check what can set event_triggered, you will see. > > > > > > > > > > > > > > > > > > > > > > > And the > > > > > event_triggered is somehow duplicated with the > > > > > VRING_AVAIL_F_NO_INTERRUPT in the case of event index. The correct fix > > > > > might be: > > > > > > > > > > 1) remove event_triggered > > > > > 2) set VRING_AVAIL_F_NO_INTERRUPT in avail_flags_shadow in > > > > > vring_interrrupt if event index is supported > > > > > > > > > > ? > > > > > > > > > > Thanks > > > > > > > > I am not sure all this is right and I'd rather we focused > > > > performance/correctness and cleanups separately. > > > > > > > > > > > > > > > > > > > > > > > > > > > But because of the introduction of event_triggered, here, > > > > > > virtqueue_get_buf_ctx_split cannot be recognized > > > > > > that the interrupt has been turned off. > > > > > > > > > > > > if we want another interrupt for the next entry, We should probably > > > > > > call virtqueue_enable_cb? > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > virtio_store_mb(vq->weak_barriers, > > > > > > > > &vring_used_event(&vq->split.vring), > > > > > > > > cpu_to_virtio16(_vq->vdev, vq->last_used_idx)); > > > > > > > > @@ -1529,7 +1530,8 @@ static void *virtqueue_get_buf_ctx_packed(struct virtqueue *_vq, > > > > > > > > * by writing event index and flush out the write before > > > > > > > > * the read in the next get_buf call. > > > > > > > > */ > > > > > > > > - if (vq->packed.event_flags_shadow == VRING_PACKED_EVENT_FLAG_DESC) > > > > > > > > + if (vq->packed.event_flags_shadow == VRING_PACKED_EVENT_FLAG_DESC > > > > > > > > + && (vq->event_triggered == false)) > > > > > > > > virtio_store_mb(vq->weak_barriers, > > > > > > > > &vq->packed.vring.driver->off_wrap, > > > > > > > > cpu_to_le16(vq->last_used_idx)); > > > > > > > > -- > > > > > > > > 2.31.1 > > > > > > > > > > > > > > > > > > > > > > > > > > >