Message ID | 20221215032719.72294-1-jasowang@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:e747:0:0:0:0:0 with SMTP id c7csp117562wrn; Wed, 14 Dec 2022 19:31:51 -0800 (PST) X-Google-Smtp-Source: AA0mqf5551k9La4ZGuat2zPo/55Uu79znbsiBZiVbZ3u53SFza1NSSHH+wPReUPFKwQSYw5LPE5a X-Received: by 2002:aa7:8c04:0:b0:578:202d:a33e with SMTP id c4-20020aa78c04000000b00578202da33emr21049008pfd.20.1671075111564; Wed, 14 Dec 2022 19:31:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1671075111; cv=none; d=google.com; s=arc-20160816; b=eac4yP7WNKnIVNCSDrLKDRXTReFlkB7UGxqVoOW27ufjCDCa+3F9H8+CGizMFp4cVC /saSEn/rJdpzCWTDpR2HxsLW+x5VTQU4/I1lVxgoWn0l5cLe8p2gYGnwvTqYwa9P0cRv I47sfUw62bMr0CnhBI27uoByChJv5YthVFvBW7ww6ooOpQaziPINuo5LH/+yeM90ml+S 6683hvXOczKflvnOcS+wIKPH/FGs2D0VmWaKjhlsKRCDlaNQjRX2OT6cmrLvXUJHAFVB MKqshl7ry/AVAReSYOU3HdtdQjYRmBdn3sIN6AlxXBmf4xG5Ipv4l75SI87dkL8tokDB a2xg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=PymI4q7qNfGWX3YIwL6NoS6LPNMzpnl2I9EurJsvLII=; b=i/D53lls6LbDlYDU/pQYgvw7UxKxE81ph/cVOjD6HrbXCmgfkwlYb90rRCso33irh0 8xxcAQot3VdI0w3PwJFfw4MztDlnM/jp3PA7ksszsnQR26fi7plI7OLcpub9oKbUEwpV vqDppay7ptCRn/4Mc4qHu746Tir5LDrNxTdciYP2SqPs91aPZrIzqOkVJwoFyEI0YRJ1 04/GMMhT42Pmx2bG9LKn9mUivhJJDrR43RlTBBKubt7RUMaqnvvfdwupAf47AjLSoBU3 mmI7GoX3IA/1qiudT2Lm/ERkCq5oLzanke9g8+I+5pWzmGNnw4Uasm1YOqq1YuoO/HsM Xxzw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=OkxoJDg1; 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: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 138-20020a621490000000b00562a1693523si1488761pfu.20.2022.12.14.19.31.34; Wed, 14 Dec 2022 19:31:51 -0800 (PST) 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=OkxoJDg1; 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 S229462AbiLOD22 (ORCPT <rfc822;jeantsuru.cumc.mandola@gmail.com> + 99 others); Wed, 14 Dec 2022 22:28:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42734 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229448AbiLOD2Y (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 14 Dec 2022 22:28:24 -0500 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 B06464A5AF for <linux-kernel@vger.kernel.org>; Wed, 14 Dec 2022 19:27:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1671074855; 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; bh=PymI4q7qNfGWX3YIwL6NoS6LPNMzpnl2I9EurJsvLII=; b=OkxoJDg19C+J0xqjjUAD4LFSlCwHy718gVr2UeXgFpEwrU+0Y1hEJGLTSSVCSklxXuLQq2 oSqGCQ5i4WYnDMlAgaSXEOA5aoZYjCVkXctAgYKKHc+cIQXixEacRBeCvPuDA3jbptlMTl 6nQquf2ACxjNFV/Ex87jg4TbKmTm8no= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-609-kma6sXGIOKKmlWPHWJxdxw-1; Wed, 14 Dec 2022 22:27:32 -0500 X-MC-Unique: kma6sXGIOKKmlWPHWJxdxw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 47D081C02D47; Thu, 15 Dec 2022 03:27:32 +0000 (UTC) Received: from localhost.localdomain (ovpn-12-112.pek2.redhat.com [10.72.12.112]) by smtp.corp.redhat.com (Postfix) with ESMTP id 18DC1C15BA0; Thu, 15 Dec 2022 03:27:21 +0000 (UTC) From: Jason Wang <jasowang@redhat.com> To: mst@redhat.com, jasowang@redhat.com, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com Cc: virtualization@lists.linux-foundation.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, xuanzhuo@linux.alibaba.com Subject: [PATCH net V2] virtio-net: correctly enable callback during start_xmit Date: Thu, 15 Dec 2022 11:27:19 +0800 Message-Id: <20221215032719.72294-1-jasowang@redhat.com> MIME-Version: 1.0 Content-type: text/plain Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,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 autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1752249256045072291?= X-GMAIL-MSGID: =?utf-8?q?1752249256045072291?= |
Series |
[net,V2] virtio-net: correctly enable callback during start_xmit
|
|
Commit Message
Jason Wang
Dec. 15, 2022, 3:27 a.m. UTC
Commit a7766ef18b33("virtio_net: disable cb aggressively") enables
virtqueue callback via the following statement:
do {
......
} while (use_napi && kick &&
unlikely(!virtqueue_enable_cb_delayed(sq->vq)));
When NAPI is used and kick is false, the callback won't be enabled
here. And when the virtqueue is about to be full, the tx will be
disabled, but we still don't enable tx interrupt which will cause a TX
hang. This could be observed when using pktgen with burst enabled.
Fixing this by trying to enable tx interrupt after we disable TX when
we're not using napi or kick is false.
Fixes: a7766ef18b33 ("virtio_net: disable cb aggressively")
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
The patch is needed for -stable.
Changes since V1:
- enable tx interrupt after we disable tx
---
drivers/net/virtio_net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Thu, Dec 15, 2022 at 11:27:19AM +0800, Jason Wang wrote: > Commit a7766ef18b33("virtio_net: disable cb aggressively") enables > virtqueue callback via the following statement: > > do { > ...... > } while (use_napi && kick && > unlikely(!virtqueue_enable_cb_delayed(sq->vq))); > > When NAPI is used and kick is false, the callback won't be enabled > here. And when the virtqueue is about to be full, the tx will be > disabled, but we still don't enable tx interrupt which will cause a TX > hang. This could be observed when using pktgen with burst enabled. > > Fixing this by trying to enable tx interrupt after we disable TX when > we're not using napi or kick is false. > > Fixes: a7766ef18b33 ("virtio_net: disable cb aggressively") > Signed-off-by: Jason Wang <jasowang@redhat.com> > --- > The patch is needed for -stable. > Changes since V1: > - enable tx interrupt after we disable tx > --- > drivers/net/virtio_net.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c > index 86e52454b5b5..dcf3a536d78a 100644 > --- a/drivers/net/virtio_net.c > +++ b/drivers/net/virtio_net.c > @@ -1873,7 +1873,7 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev) > */ > if (sq->vq->num_free < 2+MAX_SKB_FRAGS) { > netif_stop_subqueue(dev, qnum); > - if (!use_napi && > + if ((!use_napi || !kick) && > unlikely(!virtqueue_enable_cb_delayed(sq->vq))) { > /* More just got used, free them then recheck. */ > free_old_xmit_skbs(sq, false); This will work but the following lines are: if (sq->vq->num_free >= 2+MAX_SKB_FRAGS) { netif_start_subqueue(dev, qnum); virtqueue_disable_cb(sq->vq); } and I thought we are supposed to keep callbacks enabled with napi? One of the ideas of napi is to free on napi callback, not here immediately. I think it is easier to just do a separate branch here. Along the lines of: if (use_napi) { if (unlikely(!virtqueue_enable_cb_delayed(sq->vq))) virtqueue_napi_schedule(napi, vq); } else { ... old code ... } also reduces chances of regressions on !napi (which is not well tested) and keeps callbacks off while we free skbs. No? > -- > 2.25.1
On Thu, Dec 15, 2022 at 5:02 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > On Thu, Dec 15, 2022 at 11:27:19AM +0800, Jason Wang wrote: > > Commit a7766ef18b33("virtio_net: disable cb aggressively") enables > > virtqueue callback via the following statement: > > > > do { > > ...... > > } while (use_napi && kick && > > unlikely(!virtqueue_enable_cb_delayed(sq->vq))); > > > > When NAPI is used and kick is false, the callback won't be enabled > > here. And when the virtqueue is about to be full, the tx will be > > disabled, but we still don't enable tx interrupt which will cause a TX > > hang. This could be observed when using pktgen with burst enabled. > > > > Fixing this by trying to enable tx interrupt after we disable TX when > > we're not using napi or kick is false. > > > > Fixes: a7766ef18b33 ("virtio_net: disable cb aggressively") > > Signed-off-by: Jason Wang <jasowang@redhat.com> > > --- > > The patch is needed for -stable. > > Changes since V1: > > - enable tx interrupt after we disable tx > > --- > > drivers/net/virtio_net.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c > > index 86e52454b5b5..dcf3a536d78a 100644 > > --- a/drivers/net/virtio_net.c > > +++ b/drivers/net/virtio_net.c > > @@ -1873,7 +1873,7 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev) > > */ > > if (sq->vq->num_free < 2+MAX_SKB_FRAGS) { > > netif_stop_subqueue(dev, qnum); > > - if (!use_napi && > > + if ((!use_napi || !kick) && > > unlikely(!virtqueue_enable_cb_delayed(sq->vq))) { > > /* More just got used, free them then recheck. */ > > free_old_xmit_skbs(sq, false); > > This will work but the following lines are: > > if (sq->vq->num_free >= 2+MAX_SKB_FRAGS) { > netif_start_subqueue(dev, qnum); > virtqueue_disable_cb(sq->vq); > } > > > and I thought we are supposed to keep callbacks enabled with napi? This seems to be the opposite logic of commit a7766ef18b33 that disables callbacks for NAPI. It said: There are currently two cases where we poll TX vq not in response to a callback: start xmit and rx napi. We currently do this with callbacks enabled which can cause extra interrupts from the card. Used not to be a big issue as we run with interrupts disabled but that is no longer the case, and in some cases the rate of spurious interrupts is so high linux detects this and actually kills the interrupt. My undersatnding is that it tries to disable callbacks on TX. > One of the ideas of napi is to free on napi callback, not here > immediately. > > I think it is easier to just do a separate branch here. Along the > lines of: > > if (use_napi) { > if (unlikely(!virtqueue_enable_cb_delayed(sq->vq))) > virtqueue_napi_schedule(napi, vq); This seems to be a new logic and it causes some delay in processing TX (unnecessary NAPI). > } else { > ... old code ... > } > > also reduces chances of regressions on !napi (which is not well tested) > and keeps callbacks off while we free skbs. I think my patch doesn't change the logic of !napi? (It checks !napi || kick). Thanks > > No? > > > > -- > > 2.25.1 >
On Thu, Dec 15, 2022 at 05:15:43PM +0800, Jason Wang wrote: > On Thu, Dec 15, 2022 at 5:02 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > On Thu, Dec 15, 2022 at 11:27:19AM +0800, Jason Wang wrote: > > > Commit a7766ef18b33("virtio_net: disable cb aggressively") enables > > > virtqueue callback via the following statement: > > > > > > do { > > > ...... > > > } while (use_napi && kick && > > > unlikely(!virtqueue_enable_cb_delayed(sq->vq))); > > > > > > When NAPI is used and kick is false, the callback won't be enabled > > > here. And when the virtqueue is about to be full, the tx will be > > > disabled, but we still don't enable tx interrupt which will cause a TX > > > hang. This could be observed when using pktgen with burst enabled. > > > > > > Fixing this by trying to enable tx interrupt after we disable TX when > > > we're not using napi or kick is false. > > > > > > Fixes: a7766ef18b33 ("virtio_net: disable cb aggressively") > > > Signed-off-by: Jason Wang <jasowang@redhat.com> > > > --- > > > The patch is needed for -stable. > > > Changes since V1: > > > - enable tx interrupt after we disable tx > > > --- > > > drivers/net/virtio_net.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c > > > index 86e52454b5b5..dcf3a536d78a 100644 > > > --- a/drivers/net/virtio_net.c > > > +++ b/drivers/net/virtio_net.c > > > @@ -1873,7 +1873,7 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev) > > > */ > > > if (sq->vq->num_free < 2+MAX_SKB_FRAGS) { > > > netif_stop_subqueue(dev, qnum); > > > - if (!use_napi && > > > + if ((!use_napi || !kick) && > > > unlikely(!virtqueue_enable_cb_delayed(sq->vq))) { > > > /* More just got used, free them then recheck. */ > > > free_old_xmit_skbs(sq, false); > > > > This will work but the following lines are: > > > > if (sq->vq->num_free >= 2+MAX_SKB_FRAGS) { > > netif_start_subqueue(dev, qnum); > > virtqueue_disable_cb(sq->vq); > > } > > > > > > and I thought we are supposed to keep callbacks enabled with napi? > > This seems to be the opposite logic of commit a7766ef18b33 that > disables callbacks for NAPI. > > It said: > > There are currently two cases where we poll TX vq not in response to a > callback: start xmit and rx napi. We currently do this with callbacks > enabled which can cause extra interrupts from the card. Used not to be > a big issue as we run with interrupts disabled but that is no longer the > case, and in some cases the rate of spurious interrupts is so high > linux detects this and actually kills the interrupt. > > My undersatnding is that it tries to disable callbacks on TX. I think we want to disable callbacks while polling, yes. here we are not polling, and I think we want a callback because otherwise nothing will orphan skbs and a socket can be blocked, not transmitting anything - a deadlock. > > One of the ideas of napi is to free on napi callback, not here > > immediately. > > > > I think it is easier to just do a separate branch here. Along the > > lines of: > > > > if (use_napi) { > > if (unlikely(!virtqueue_enable_cb_delayed(sq->vq))) > > virtqueue_napi_schedule(napi, vq); > > This seems to be a new logic and it causes some delay in processing TX > (unnecessary NAPI). That's good, we overloaded the queue so we are already going too fast, deferring tx so queue has chance to drain will allow better batching in the qdisc. > > } else { > > ... old code ... > > } > > > > also reduces chances of regressions on !napi (which is not well tested) > > and keeps callbacks off while we free skbs. > > I think my patch doesn't change the logic of !napi? (It checks !napi || kick). > > Thanks I agree it doesn't seem to as written. > > > > No? > > > > > > > -- > > > 2.25.1 > >
On Thu, Dec 15, 2022 at 5:35 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > On Thu, Dec 15, 2022 at 05:15:43PM +0800, Jason Wang wrote: > > On Thu, Dec 15, 2022 at 5:02 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > > > On Thu, Dec 15, 2022 at 11:27:19AM +0800, Jason Wang wrote: > > > > Commit a7766ef18b33("virtio_net: disable cb aggressively") enables > > > > virtqueue callback via the following statement: > > > > > > > > do { > > > > ...... > > > > } while (use_napi && kick && > > > > unlikely(!virtqueue_enable_cb_delayed(sq->vq))); > > > > > > > > When NAPI is used and kick is false, the callback won't be enabled > > > > here. And when the virtqueue is about to be full, the tx will be > > > > disabled, but we still don't enable tx interrupt which will cause a TX > > > > hang. This could be observed when using pktgen with burst enabled. > > > > > > > > Fixing this by trying to enable tx interrupt after we disable TX when > > > > we're not using napi or kick is false. > > > > > > > > Fixes: a7766ef18b33 ("virtio_net: disable cb aggressively") > > > > Signed-off-by: Jason Wang <jasowang@redhat.com> > > > > --- > > > > The patch is needed for -stable. > > > > Changes since V1: > > > > - enable tx interrupt after we disable tx > > > > --- > > > > drivers/net/virtio_net.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c > > > > index 86e52454b5b5..dcf3a536d78a 100644 > > > > --- a/drivers/net/virtio_net.c > > > > +++ b/drivers/net/virtio_net.c > > > > @@ -1873,7 +1873,7 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev) > > > > */ > > > > if (sq->vq->num_free < 2+MAX_SKB_FRAGS) { > > > > netif_stop_subqueue(dev, qnum); > > > > - if (!use_napi && > > > > + if ((!use_napi || !kick) && > > > > unlikely(!virtqueue_enable_cb_delayed(sq->vq))) { > > > > /* More just got used, free them then recheck. */ > > > > free_old_xmit_skbs(sq, false); > > > > > > This will work but the following lines are: > > > > > > if (sq->vq->num_free >= 2+MAX_SKB_FRAGS) { > > > netif_start_subqueue(dev, qnum); > > > virtqueue_disable_cb(sq->vq); > > > } > > > > > > > > > and I thought we are supposed to keep callbacks enabled with napi? > > > > This seems to be the opposite logic of commit a7766ef18b33 that > > disables callbacks for NAPI. > > > > It said: > > > > There are currently two cases where we poll TX vq not in response to a > > callback: start xmit and rx napi. We currently do this with callbacks > > enabled which can cause extra interrupts from the card. Used not to be > > a big issue as we run with interrupts disabled but that is no longer the > > case, and in some cases the rate of spurious interrupts is so high > > linux detects this and actually kills the interrupt. > > > > My undersatnding is that it tries to disable callbacks on TX. > > I think we want to disable callbacks while polling, yes. here we are not > polling, and I think we want a callback because otherwise nothing will > orphan skbs and a socket can be blocked, not transmitting anything - a > deadlock. I'm not sure how I got here, did you mean a partial revert of a7766ef18b33 (the part that disables TX callbacks on start_xmit)? Btw, I plan to remove non NAPI mode completely, since it was disabled by default for years and we don't see any complaint, then we may have modern features like BQL and better TCP performance. In that sense we may simply keep tx callback open as most of modern NIC did. > > > > One of the ideas of napi is to free on napi callback, not here > > > immediately. > > > > > > I think it is easier to just do a separate branch here. Along the > > > lines of: > > > > > > if (use_napi) { > > > if (unlikely(!virtqueue_enable_cb_delayed(sq->vq))) > > > virtqueue_napi_schedule(napi, vq); > > > > This seems to be a new logic and it causes some delay in processing TX > > (unnecessary NAPI). > > That's good, we overloaded the queue so we are already going > too fast, deferring tx so queue has chance to drain > will allow better batching in the qdisc. I meant, compare to 1) schedule NAPI and poll TX The current code did 2) poll TX immediately 2) seems faster? Thanks > > > > } else { > > > ... old code ... > > > } > > > > > > also reduces chances of regressions on !napi (which is not well tested) > > > and keeps callbacks off while we free skbs. > > > > I think my patch doesn't change the logic of !napi? (It checks !napi || kick). > > > > Thanks > > I agree it doesn't seem to as written. > > > > > > > No? > > > > > > > > > > -- > > > > 2.25.1 > > > >
On Fri, Dec 16, 2022 at 11:43 AM Jason Wang <jasowang@redhat.com> wrote: > > On Thu, Dec 15, 2022 at 5:35 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > On Thu, Dec 15, 2022 at 05:15:43PM +0800, Jason Wang wrote: > > > On Thu, Dec 15, 2022 at 5:02 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > > > > > On Thu, Dec 15, 2022 at 11:27:19AM +0800, Jason Wang wrote: > > > > > Commit a7766ef18b33("virtio_net: disable cb aggressively") enables > > > > > virtqueue callback via the following statement: > > > > > > > > > > do { > > > > > ...... > > > > > } while (use_napi && kick && > > > > > unlikely(!virtqueue_enable_cb_delayed(sq->vq))); > > > > > > > > > > When NAPI is used and kick is false, the callback won't be enabled > > > > > here. And when the virtqueue is about to be full, the tx will be > > > > > disabled, but we still don't enable tx interrupt which will cause a TX > > > > > hang. This could be observed when using pktgen with burst enabled. > > > > > > > > > > Fixing this by trying to enable tx interrupt after we disable TX when > > > > > we're not using napi or kick is false. > > > > > > > > > > Fixes: a7766ef18b33 ("virtio_net: disable cb aggressively") > > > > > Signed-off-by: Jason Wang <jasowang@redhat.com> > > > > > --- > > > > > The patch is needed for -stable. > > > > > Changes since V1: > > > > > - enable tx interrupt after we disable tx > > > > > --- > > > > > drivers/net/virtio_net.c | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c > > > > > index 86e52454b5b5..dcf3a536d78a 100644 > > > > > --- a/drivers/net/virtio_net.c > > > > > +++ b/drivers/net/virtio_net.c > > > > > @@ -1873,7 +1873,7 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev) > > > > > */ > > > > > if (sq->vq->num_free < 2+MAX_SKB_FRAGS) { > > > > > netif_stop_subqueue(dev, qnum); > > > > > - if (!use_napi && > > > > > + if ((!use_napi || !kick) && > > > > > unlikely(!virtqueue_enable_cb_delayed(sq->vq))) { > > > > > /* More just got used, free them then recheck. */ > > > > > free_old_xmit_skbs(sq, false); > > > > > > > > This will work but the following lines are: > > > > > > > > if (sq->vq->num_free >= 2+MAX_SKB_FRAGS) { > > > > netif_start_subqueue(dev, qnum); > > > > virtqueue_disable_cb(sq->vq); > > > > } > > > > > > > > > > > > and I thought we are supposed to keep callbacks enabled with napi? > > > > > > This seems to be the opposite logic of commit a7766ef18b33 that > > > disables callbacks for NAPI. > > > > > > It said: > > > > > > There are currently two cases where we poll TX vq not in response to a > > > callback: start xmit and rx napi. We currently do this with callbacks > > > enabled which can cause extra interrupts from the card. Used not to be > > > a big issue as we run with interrupts disabled but that is no longer the > > > case, and in some cases the rate of spurious interrupts is so high > > > linux detects this and actually kills the interrupt. > > > > > > My undersatnding is that it tries to disable callbacks on TX. > > > > I think we want to disable callbacks while polling, yes. here we are not > > polling, and I think we want a callback because otherwise nothing will > > orphan skbs and a socket can be blocked, not transmitting anything - a > > deadlock. > > I'm not sure how I got here, did you mean a partial revert of > a7766ef18b33 (the part that disables TX callbacks on start_xmit)? Michael, any idea on this? Thanks > > Btw, I plan to remove non NAPI mode completely, since it was disabled > by default for years and we don't see any complaint, then we may have > modern features like BQL and better TCP performance. In that sense we > may simply keep tx callback open as most of modern NIC did. > > > > > > > One of the ideas of napi is to free on napi callback, not here > > > > immediately. > > > > > > > > I think it is easier to just do a separate branch here. Along the > > > > lines of: > > > > > > > > if (use_napi) { > > > > if (unlikely(!virtqueue_enable_cb_delayed(sq->vq))) > > > > virtqueue_napi_schedule(napi, vq); > > > > > > This seems to be a new logic and it causes some delay in processing TX > > > (unnecessary NAPI). > > > > That's good, we overloaded the queue so we are already going > > too fast, deferring tx so queue has chance to drain > > will allow better batching in the qdisc. > > I meant, compare to > > 1) schedule NAPI and poll TX > > The current code did > > 2) poll TX immediately > > 2) seems faster? > > Thanks > > > > > > > } else { > > > > ... old code ... > > > > } > > > > > > > > also reduces chances of regressions on !napi (which is not well tested) > > > > and keeps callbacks off while we free skbs. > > > > > > I think my patch doesn't change the logic of !napi? (It checks !napi || kick). > > > > > > Thanks > > > > I agree it doesn't seem to as written. > > > > > > > > > > No? > > > > > > > > > > > > > -- > > > > > 2.25.1 > > > > > >
在 2022/12/23 14:29, Jason Wang 写道: > On Fri, Dec 16, 2022 at 11:43 AM Jason Wang <jasowang@redhat.com> wrote: >> On Thu, Dec 15, 2022 at 5:35 PM Michael S. Tsirkin <mst@redhat.com> wrote: >>> On Thu, Dec 15, 2022 at 05:15:43PM +0800, Jason Wang wrote: >>>> On Thu, Dec 15, 2022 at 5:02 PM Michael S. Tsirkin <mst@redhat.com> wrote: >>>>> On Thu, Dec 15, 2022 at 11:27:19AM +0800, Jason Wang wrote: >>>>>> Commit a7766ef18b33("virtio_net: disable cb aggressively") enables >>>>>> virtqueue callback via the following statement: >>>>>> >>>>>> do { >>>>>> ...... >>>>>> } while (use_napi && kick && >>>>>> unlikely(!virtqueue_enable_cb_delayed(sq->vq))); >>>>>> >>>>>> When NAPI is used and kick is false, the callback won't be enabled >>>>>> here. And when the virtqueue is about to be full, the tx will be >>>>>> disabled, but we still don't enable tx interrupt which will cause a TX >>>>>> hang. This could be observed when using pktgen with burst enabled. >>>>>> >>>>>> Fixing this by trying to enable tx interrupt after we disable TX when >>>>>> we're not using napi or kick is false. >>>>>> >>>>>> Fixes: a7766ef18b33 ("virtio_net: disable cb aggressively") >>>>>> Signed-off-by: Jason Wang <jasowang@redhat.com> >>>>>> --- >>>>>> The patch is needed for -stable. >>>>>> Changes since V1: >>>>>> - enable tx interrupt after we disable tx >>>>>> --- >>>>>> drivers/net/virtio_net.c | 2 +- >>>>>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>>>> >>>>>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c >>>>>> index 86e52454b5b5..dcf3a536d78a 100644 >>>>>> --- a/drivers/net/virtio_net.c >>>>>> +++ b/drivers/net/virtio_net.c >>>>>> @@ -1873,7 +1873,7 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev) >>>>>> */ >>>>>> if (sq->vq->num_free < 2+MAX_SKB_FRAGS) { >>>>>> netif_stop_subqueue(dev, qnum); >>>>>> - if (!use_napi && >>>>>> + if ((!use_napi || !kick) && >>>>>> unlikely(!virtqueue_enable_cb_delayed(sq->vq))) { >>>>>> /* More just got used, free them then recheck. */ >>>>>> free_old_xmit_skbs(sq, false); >>>>> This will work but the following lines are: >>>>> >>>>> if (sq->vq->num_free >= 2+MAX_SKB_FRAGS) { >>>>> netif_start_subqueue(dev, qnum); >>>>> virtqueue_disable_cb(sq->vq); >>>>> } >>>>> >>>>> >>>>> and I thought we are supposed to keep callbacks enabled with napi? >>>> This seems to be the opposite logic of commit a7766ef18b33 that >>>> disables callbacks for NAPI. >>>> >>>> It said: >>>> >>>> There are currently two cases where we poll TX vq not in response to a >>>> callback: start xmit and rx napi. We currently do this with callbacks >>>> enabled which can cause extra interrupts from the card. Used not to be >>>> a big issue as we run with interrupts disabled but that is no longer the >>>> case, and in some cases the rate of spurious interrupts is so high >>>> linux detects this and actually kills the interrupt. >>>> >>>> My undersatnding is that it tries to disable callbacks on TX. >>> I think we want to disable callbacks while polling, yes. here we are not >>> polling, and I think we want a callback because otherwise nothing will >>> orphan skbs and a socket can be blocked, not transmitting anything - a >>> deadlock. >> I'm not sure how I got here, did you mean a partial revert of >> a7766ef18b33 (the part that disables TX callbacks on start_xmit)? > Michael, any idea on this? > > Thanks Michael, any comment? Thanks
On Wed, Jan 04, 2023 at 12:23:07PM +0800, Jason Wang wrote: > > 在 2022/12/23 14:29, Jason Wang 写道: > > On Fri, Dec 16, 2022 at 11:43 AM Jason Wang <jasowang@redhat.com> wrote: > > > On Thu, Dec 15, 2022 at 5:35 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > On Thu, Dec 15, 2022 at 05:15:43PM +0800, Jason Wang wrote: > > > > > On Thu, Dec 15, 2022 at 5:02 PM Michael S. Tsirkin <mst@redhat.com> wrote: > > > > > > On Thu, Dec 15, 2022 at 11:27:19AM +0800, Jason Wang wrote: > > > > > > > Commit a7766ef18b33("virtio_net: disable cb aggressively") enables > > > > > > > virtqueue callback via the following statement: > > > > > > > > > > > > > > do { > > > > > > > ...... > > > > > > > } while (use_napi && kick && > > > > > > > unlikely(!virtqueue_enable_cb_delayed(sq->vq))); > > > > > > > > > > > > > > When NAPI is used and kick is false, the callback won't be enabled > > > > > > > here. And when the virtqueue is about to be full, the tx will be > > > > > > > disabled, but we still don't enable tx interrupt which will cause a TX > > > > > > > hang. This could be observed when using pktgen with burst enabled. > > > > > > > > > > > > > > Fixing this by trying to enable tx interrupt after we disable TX when > > > > > > > we're not using napi or kick is false. > > > > > > > > > > > > > > Fixes: a7766ef18b33 ("virtio_net: disable cb aggressively") > > > > > > > Signed-off-by: Jason Wang <jasowang@redhat.com> > > > > > > > --- > > > > > > > The patch is needed for -stable. > > > > > > > Changes since V1: > > > > > > > - enable tx interrupt after we disable tx > > > > > > > --- > > > > > > > drivers/net/virtio_net.c | 2 +- > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > > > > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c > > > > > > > index 86e52454b5b5..dcf3a536d78a 100644 > > > > > > > --- a/drivers/net/virtio_net.c > > > > > > > +++ b/drivers/net/virtio_net.c > > > > > > > @@ -1873,7 +1873,7 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev) > > > > > > > */ > > > > > > > if (sq->vq->num_free < 2+MAX_SKB_FRAGS) { > > > > > > > netif_stop_subqueue(dev, qnum); > > > > > > > - if (!use_napi && > > > > > > > + if ((!use_napi || !kick) && > > > > > > > unlikely(!virtqueue_enable_cb_delayed(sq->vq))) { > > > > > > > /* More just got used, free them then recheck. */ > > > > > > > free_old_xmit_skbs(sq, false); > > > > > > This will work but the following lines are: > > > > > > > > > > > > if (sq->vq->num_free >= 2+MAX_SKB_FRAGS) { > > > > > > netif_start_subqueue(dev, qnum); > > > > > > virtqueue_disable_cb(sq->vq); > > > > > > } > > > > > > > > > > > > > > > > > > and I thought we are supposed to keep callbacks enabled with napi? > > > > > This seems to be the opposite logic of commit a7766ef18b33 that > > > > > disables callbacks for NAPI. > > > > > > > > > > It said: > > > > > > > > > > There are currently two cases where we poll TX vq not in response to a > > > > > callback: start xmit and rx napi. We currently do this with callbacks > > > > > enabled which can cause extra interrupts from the card. Used not to be > > > > > a big issue as we run with interrupts disabled but that is no longer the > > > > > case, and in some cases the rate of spurious interrupts is so high > > > > > linux detects this and actually kills the interrupt. > > > > > > > > > > My undersatnding is that it tries to disable callbacks on TX. > > > > I think we want to disable callbacks while polling, yes. here we are not > > > > polling, and I think we want a callback because otherwise nothing will > > > > orphan skbs and a socket can be blocked, not transmitting anything - a > > > > deadlock. > > > I'm not sure how I got here, did you mean a partial revert of > > > a7766ef18b33 (the part that disables TX callbacks on start_xmit)? > > Michael, any idea on this? > > > > Thanks > > > Michael, any comment? > > Thanks Sorry I don't understand the question. What does "how I got here" mean? To repeat my suggestion: I think it is easier to just do a separate branch here. Along the lines of: if (use_napi) { if (unlikely(!virtqueue_enable_cb_delayed(sq->vq))) virtqueue_napi_schedule(napi, vq); } else { ... old code ... } we can also backport this minimal safe fix, any refactorings can be done on top.
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index 86e52454b5b5..dcf3a536d78a 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@ -1873,7 +1873,7 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct net_device *dev) */ if (sq->vq->num_free < 2+MAX_SKB_FRAGS) { netif_stop_subqueue(dev, qnum); - if (!use_napi && + if ((!use_napi || !kick) && unlikely(!virtqueue_enable_cb_delayed(sq->vq))) { /* More just got used, free them then recheck. */ free_old_xmit_skbs(sq, false);