Received: by 2002:a05:6a10:7420:0:0:0:0 with SMTP id hk32csp1212842pxb; Fri, 18 Feb 2022 03:06:45 -0800 (PST) X-Google-Smtp-Source: ABdhPJwqsLcgaftlq5bhHyaeYbZhKjzPRWmnf7oIK/4jDxmhmWZXJEgXjWBqrIPcMD6SRfPhyKxO X-Received: by 2002:a17:906:4a96:b0:6c5:5ea9:5366 with SMTP id x22-20020a1709064a9600b006c55ea95366mr5975166eju.473.1645182404962; Fri, 18 Feb 2022 03:06:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1645182404; cv=none; d=google.com; s=arc-20160816; b=I59E+x8eGKNI3IlxWAhQhgY8KHqCnpWM3RGg4orfX9lIznUpEHPKTqFVMM31gBB0oW fcAZimvw1B60WmFy8Ie6EJ8fRBIjgCtXS6Wy6XcvnB0fFscmHUsp14gmc0yZr0KsevgZ 6YynAeVmSY+0PArTmMJT83a4mwmQMr1o0WonPzEXz5u0IZlzEmcF2jp6qF9dd1+7ppbE dIT4oZlEWFeir5SOQHzlUureAQdiMq9sYxfkOrXTV7cjQSNWQw+x09l6K52cpXNwArnb jzgyBItGJ3tYybMj1hSx/tnH069OzwsnLTLMwCRbA1krQPWV38tRhlhtGDV5BZ9XvvDN y34A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=0t0ig3q6Sp2mvoezO0JaagGhH+DGXuT456KDBH79FZ0=; b=NGM9oyqFl6Supp2peu/GiI21vWosLIR23fJHB7T2d+H8Xef9RZizqq3H2O3wh5qjys qqtKxYlxN6Na6MCHLvsEydAibV/b5n797+lONMOWa8A4xnrhKrv0tRfvisMB5bK8T0Ou skftx6nLnk08LPp0Vk5V013dQdD7B7ny4o4ZWdF2KpzqzZOpUu6y9zyDeFm6cjM5N4UT Y7hVLdCcldM0XmoYasvofXhPWXepm23gpJvTfQu6hkMCtzvoO4NPFCEuxaUthvcEDNdf 1xm8zmIUcG9MWxNGbaE2ue/rxvTpaM++IlARnyh1jCBS0tFJ30Ifpp1153Me9wQpFzC2 9zSw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass (test mode) header.i=@axis.com header.s=axis-central1 header.b=pHI6jFzv; 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=axis.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h2si3389572ejq.514.2022.02.18.03.06.21; Fri, 18 Feb 2022 03:06:44 -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 (test mode) header.i=@axis.com header.s=axis-central1 header.b=pHI6jFzv; 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=axis.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234040AbiBRKX0 (ORCPT + 99 others); Fri, 18 Feb 2022 05:23:26 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:52776 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230098AbiBRKXX (ORCPT ); Fri, 18 Feb 2022 05:23:23 -0500 Received: from smtp1.axis.com (smtp1.axis.com [195.60.68.17]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 424B52B1AA1; Fri, 18 Feb 2022 02:23:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axis.com; q=dns/txt; s=axis-central1; t=1645179787; x=1676715787; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=0t0ig3q6Sp2mvoezO0JaagGhH+DGXuT456KDBH79FZ0=; b=pHI6jFzvxoi0j3ne7wO34lrazDpzu6REhaVP5x9nJ/IpQKNqL3FS4GKH rf/wpDyUIngYpdO87FBPTLInPxtDaQO/tCBvjvr7L0/JxybMwot6yZqJa KmhKeD3ttWqwp5B0BSf/ip0MKs8h1l1yU6/Z/SZlngGwHVjwmQ+SrYJd6 uKfIZ9wdMECVwEmXyL3lBipUF6zMQC1KZdm1o7h/RBynLF5iH3HFP+dlS UZiUFrZ+MPLmYGI+x3DEqLhBf3DyQVoPZ3b3Bwe6U17rxSi624TbfVLW+ uE5Ca0jqMRc1VuoWPj4MMZLfpLkFvuKJGsMlJiSEJG0Fti4ytTI6fBfC3 g==; Date: Fri, 18 Feb 2022 11:23:03 +0100 From: Vincent Whitchurch To: Jakub Kicinski CC: Giuseppe Cavallaro , Alexandre Torgue , Jose Abreu , "David S. Miller" , Maxime Coquelin , kernel , Lars Persson , Srinivas Kandagatla , "netdev@vger.kernel.org" , "linux-stm32@st-md-mailman.stormreply.com" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] net: stmmac: Enable NAPI before interrupts go live Message-ID: <20220218102303.GA21458@axis.com> References: <20220217145527.2696444-1-vincent.whitchurch@axis.com> <20220217203604.39e318d0@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20220217203604.39e318d0@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE 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: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 18, 2022 at 05:36:04AM +0100, Jakub Kicinski wrote: > On Thu, 17 Feb 2022 15:55:26 +0100 Vincent Whitchurch wrote: > > The stmmac_open function has a race window between enabling the RX > > path and its interrupt to the point where napi_enabled is called. > > > > A chatty network with plenty of broadcast/multicast traffic has the > > potential to completely fill the RX ring before the interrupt handler > > is installed. In this scenario the single interrupt taken will find > > napi disabled and the RX ring will not be processed. No further RX > > interrupt will be delivered because the ring is full. > > > > The RX stall could eventually clear because the TX path will trigger a > > DMA interrupt once the tx_coal_frames threshold is reached and then > > NAPI becomes scheduled. > > LGTM, although now the ndo_open and ndo_stop paths are not symmetrical. > Is there no way to mask the IRQs so that they don't fire immediately? The initial enabling of the DMA irqs is done as part of the ->init_chan() callback inside the various variants. We could use the ->disable_dma_irq() callback to to disable the DMA irqs and only enable them at the end of the init sequence with a stmmac_enable_all_dma_irq(). This avoids having to change all the variants and there should be no problem in calling ->disable_dma_irq() after the interrupts have been momentarily enabled in ->stmmac_init_chan() since the DMA is reset before these calls and not started until later. Note that I haven't added a symmetrical stmmac_disable_all_dma_irq() at the top of stmmac_release() before the NAPI disable since I can't see that it would do any good there since NAPI can re-enable DMA irqs. > More common flow (IMO) would be: > - request irq > - mask irq > - populate rings > - start dma > - enable napi > - unmask irq I don't think this driver has ever followed this exact sequence, but the request_irq() was done before the "start dma" and the "enable napi" before the commit mentioned in the Fixes: tag. But that's quite a while ago and the driver has changed a lot since then and gotten support for a lot of variants and features which I can't test, so I didn't dare to rewrite the entire init sequence. > Other than the difference in flow between open/stop there may also be > some unpleasantness around restarting tx queues twice with the patch > as is. New patch below, it works for me (though I don't have hardware with working suspend/resume support). I will send it out as a v2 if there are no objections. Thanks. 8<----- diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index 6708ca2aa4f7..43978558d6c0 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -2260,6 +2260,23 @@ static void stmmac_stop_tx_dma(struct stmmac_priv *priv, u32 chan) stmmac_stop_tx(priv, priv->ioaddr, chan); } +static void stmmac_enable_all_dma_irq(struct stmmac_priv *priv) +{ + u32 rx_channels_count = priv->plat->rx_queues_to_use; + u32 tx_channels_count = priv->plat->tx_queues_to_use; + u32 dma_csr_ch = max(rx_channels_count, tx_channels_count); + u32 chan; + + for (chan = 0; chan < dma_csr_ch; chan++) { + struct stmmac_channel *ch = &priv->channel[chan]; + unsigned long flags; + + spin_lock_irqsave(&ch->lock, flags); + stmmac_enable_dma_irq(priv, priv->ioaddr, chan, 1, 1); + spin_unlock_irqrestore(&ch->lock, flags); + } +} + /** * stmmac_start_all_dma - start all RX and TX DMA channels * @priv: driver private structure @@ -2902,8 +2919,10 @@ static int stmmac_init_dma_engine(struct stmmac_priv *priv) stmmac_axi(priv, priv->ioaddr, priv->plat->axi); /* DMA CSR Channel configuration */ - for (chan = 0; chan < dma_csr_ch; chan++) + for (chan = 0; chan < dma_csr_ch; chan++) { stmmac_init_chan(priv, priv->ioaddr, priv->plat->dma_cfg, chan); + stmmac_disable_dma_irq(priv, priv->ioaddr, chan, 1, 1); + } /* DMA RX Channel Configuration */ for (chan = 0; chan < rx_channels_count; chan++) { @@ -3759,6 +3778,7 @@ static int stmmac_open(struct net_device *dev) stmmac_enable_all_queues(priv); netif_tx_start_all_queues(priv->dev); + stmmac_enable_all_dma_irq(priv); return 0; @@ -6508,8 +6528,10 @@ int stmmac_xdp_open(struct net_device *dev) } /* DMA CSR Channel configuration */ - for (chan = 0; chan < dma_csr_ch; chan++) + for (chan = 0; chan < dma_csr_ch; chan++) { stmmac_init_chan(priv, priv->ioaddr, priv->plat->dma_cfg, chan); + stmmac_disable_dma_irq(priv, priv->ioaddr, chan, 1, 1); + } /* Adjust Split header */ sph_en = (priv->hw->rx_csum > 0) && priv->sph; @@ -6570,6 +6592,7 @@ int stmmac_xdp_open(struct net_device *dev) stmmac_enable_all_queues(priv); netif_carrier_on(dev); netif_tx_start_all_queues(dev); + stmmac_enable_all_dma_irq(priv); return 0; @@ -7447,6 +7470,7 @@ int stmmac_resume(struct device *dev) stmmac_restore_hw_vlan_rx_fltr(priv, ndev, priv->hw); stmmac_enable_all_queues(priv); + stmmac_enable_all_dma_irq(priv); mutex_unlock(&priv->lock); rtnl_unlock();