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 smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D6406C77B61 for ; Thu, 13 Apr 2023 07:21:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 68EDD418A8; Thu, 13 Apr 2023 07:21:06 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 68EDD418A8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osuosl.org; s=default; t=1681370466; bh=0cmWMnNKB2IUAU8AqdqIXkdnovWRoC7ZFfjxP9ZEGhg=; h=From:To:In-Reply-To:References:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc:From; b=to+vbRxY7ut11KrwmuJzHXKVbPWJhIcV8pfuWjK/t6h5F9F5XR+KpKwI8D+sY23gx JOyiS3O4h+q18uB5r4wdj/65IlSSwRhHtxgURT5LKuFk1LS9t2ZYDUsOuOA5f++WNY 8zUyKL6qGqpUNEQPuWsAlAdAMBxpqZqrHxDHJDQC1WoYDcN2byKqU4xoD+SUsYv1LP UWkpyNvY5V2h+PR85jcEW7P+JxCmsDvlt0KsgoiCyfcsQp4z3j+QvhzMGH57Ha8igy WL1WI2SW3vRvL1g+AQU4W/8Ei2QSJDR0xBEHEU5i/0KU6Jo9xVhMPp4DszO7OQVjwv YyAEOZpd0JjMw== X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZvucrUcD0zh; Thu, 13 Apr 2023 07:21:05 +0000 (UTC) Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by smtp4.osuosl.org (Postfix) with ESMTP id 2CA58418AA; Thu, 13 Apr 2023 07:21:05 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 2CA58418AA Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by ash.osuosl.org (Postfix) with ESMTP id 601101BF288 for ; Thu, 13 Apr 2023 07:21:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 4496F83EDF for ; Thu, 13 Apr 2023 07:21:04 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 4496F83EDF X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1XEXVp16_9F for ; Thu, 13 Apr 2023 07:21:02 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 10C9283ED5 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by smtp1.osuosl.org (Postfix) with ESMTPS id 10C9283ED5 for ; Thu, 13 Apr 2023 07:21:01 +0000 (UTC) From: Kurt Kanzenbach To: Jacob Keller , Jesse Brandeburg , Tony Nguyen In-Reply-To: <1809a34d-dcf4-4b54-089a-a7be3f4c23e1@intel.com> References: <20230412073611.62942-1-kurt@linutronix.de> <1809a34d-dcf4-4b54-089a-a7be3f4c23e1@intel.com> Date: Thu, 13 Apr 2023 09:20:57 +0200 Message-ID: <874jpk2qp2.fsf@kurt> MIME-Version: 1.0 X-Mailman-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1681370459; 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: in-reply-to:in-reply-to:references:references; bh=Gf8o/adbOI2wRHyAYHOuUl4w2xDShw502p6uq1yjW/o=; b=jd0nFk877ojN78H+xnoNZJ21TJY8IunD0mL0OMSkHT8cJWKHhKCmjsXX1SZDtHp6OLzOZp NICA8IzoOwv7zD95uzyVTkDBmzx18xtGUPeNehe1RiPxbCqrnHuNaiW1zgsUpZOsMhihpm 2ZTYF0YzDIuwhgmX+BstzaRDWE0w1WA+nM+mEIrhwpgeNgnbBSQiRjvCKEp3ygKClUMPlq K5uJftvEczJMAuN1U/U4sIGgzf/pEvTXBAg3Xk4/AMA7SzwSs2L6VQbv4jesLq2vYkX4iI /QHeBkApg8ydOjrkLzqp1rD0dWqlSlTfd8sFUwqs2iRqr3Oa6KaKh+3nb+OX6Q== X-Mailman-Original-DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1681370459; 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: in-reply-to:in-reply-to:references:references; bh=Gf8o/adbOI2wRHyAYHOuUl4w2xDShw502p6uq1yjW/o=; b=55cEtF6OKAcYwqDBb/O/ndO9DLSWPvumJVkEmWH/bw0Mg3gePHry7BysvkfLRWfZsiUbcp geJacF7BdpyxHGAQ== X-Mailman-Original-Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.a=rsa-sha256 header.s=2020 header.b=jd0nFk87; dkim=pass header.d=linutronix.de header.i=@linutronix.de header.a=ed25519-sha256 header.s=2020e header.b=55cEtF6O Subject: Re: [Intel-wired-lan] [PATCH net-next] igc: Avoid transmit queue timeout for XDP X-BeenThere: intel-wired-lan@osuosl.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Wired Ethernet Linux Kernel Driver Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: netdev@vger.kernel.org, Eric Dumazet , intel-wired-lan@lists.osuosl.org, Ong Boon Leong , Jakub Kicinski , Paolo Abeni , "David S. Miller" Content-Type: multipart/mixed; boundary="===============4207764579087586661==" Errors-To: intel-wired-lan-bounces@osuosl.org Sender: "Intel-wired-lan" --===============4207764579087586661== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed Apr 12 2023, Jacob Keller wrote: > On 4/12/2023 12:36 AM, Kurt Kanzenbach wrote: >> High XDP load triggers the netdev watchdog: >>=20 >> |NETDEV WATCHDOG: enp3s0 (igc): transmit queue 2 timed out >>=20 >> The reason is the Tx queue transmission start (txq->trans_start) is not = updated >> in XDP code path. Therefore, add it for all XDP transmission functions. >>=20 >> Signed-off-by: Kurt Kanzenbach > > For Intel, I only see this being done in igb, as 5337824f4dc4 ("net: > annotate accesses to queue->trans_start"). I see a few other drivers > also calling this. > > Is this a gap that other XDP implementations also need to fix? > > grepping for txq_trans_cond_update I see: > >> apm/xgene/xgene_enet_main.c >> 874: txq_trans_cond_update(txq); >>=20 >> engleder/tsnep_main.c >> 623: txq_trans_cond_update(tx_nq); >> 1660: txq_trans_cond_update(nq); >>=20 >> freescale/dpaa/dpaa_eth.c >> 2347: txq_trans_cond_update(txq); >> 2553: txq_trans_cond_update(txq); >>=20 >> ibm/ibmvnic.c >> 2485: txq_trans_cond_update(txq); >>=20 >> intel/igb/igb_main.c >> 2980: txq_trans_cond_update(nq); >> 3014: txq_trans_cond_update(nq); >>=20 >> stmicro/stmmac/stmmac_main.c >> 2428: txq_trans_cond_update(nq); >> 4808: txq_trans_cond_update(nq); >> 6436: txq_trans_cond_update(nq); >>=20 > > Is most driver's XDP implementation broken? There's also > netif_trans_update but this is called out as a legacy only function. Far > more drivers call this but I don't see either call or a direct update to > trans_start in many XDP implementations... > > Am I missing something or are a bunch of other XDP implementations also > wrong? > > The patch seems ok to me, assuming this is the correct way to fix things > and not something in the XDP path. AFAICT the netdev watchdog is only started when the device exposes ndo_tx_timeout callback (see __netdev_watchdog_up()). For igc this callback was introduced recently in 9b275176270e ("igc: Add ndo_tx_timeout support"). My guess, as soon as the net device has ndo_tx_timeout it needs to maintain trans_start for XDP? Thanks, Kurt --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJHBAEBCgAxFiEEvLm/ssjDfdPf21mSwZPR8qpGc4IFAmQ3rVkTHGt1cnRAbGlu dXRyb25peC5kZQAKCRDBk9HyqkZzgibTD/0S41/87v4PI039H0WiQE3mh+bEA9rP I8IbnifWL8hhJGedZBCucDwNuSsXADxiHrSLKVGdz0UjgFJExkMGrSEvBFrV0Zs4 MYuMTlw/wYTF4KN5YBYqkzCsIuzrl+yGdhtBDcuTaxl0YLzF6xUP7yALAtyZgY+1 +u15zKytCypI5FDB1VqfNiOc3kw6NtfvCxTZQwPuBC8ZP6jF+qrG0xI+ldnjnXl3 0qJyRQCdE7+cfY7/meuZRtipP6WLcOLjUofUnHVCnXmLituzWgY8ZS/nQA9yiEvU Wo9OdTcUmof8R7cLKcQZbtf4v97CtAy6oYbONUHPDePcmDJhAO92fvmGty0GQH32 oBfOVCy2fzJ9lf4rjOKRmXYauCVtGmZDTAFcQakN1T+PXYdZku9RTp06I+JTKhgh MPl7tyCYw4Vr576N9GLc928XIXB5WR1ADokAvgZ6zQtiVDKnM+az4MHmXfo4rHcG BXm2zu4zQrC/DkW8CsfjcdCaloa62OlxthfD5kCkvh/Ew70E+DCJSeQGfTr4Dxkg oO9GmxaVziXwOGuyYR4giygCHmNbPsSPK2uWRQ5VcTRjZwzYpV8Rv2NKy7ZHRsgk 7swx2IYnVijlnWri2S4rsMXxqR5QkfqdCmOTXlwWukWUE9i8JTo2/EX2kx2Z+/j3 FNJeiexMFBINug== =iqmd -----END PGP SIGNATURE----- --=-=-=-- --===============4207764579087586661== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Intel-wired-lan mailing list Intel-wired-lan@osuosl.org https://lists.osuosl.org/mailman/listinfo/intel-wired-lan --===============4207764579087586661==-- 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 D2173C77B6C for ; Thu, 13 Apr 2023 07:21:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229742AbjDMHVH (ORCPT ); Thu, 13 Apr 2023 03:21:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37252 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229530AbjDMHVG (ORCPT ); Thu, 13 Apr 2023 03:21:06 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F1D0459F4 for ; Thu, 13 Apr 2023 00:21:01 -0700 (PDT) From: Kurt Kanzenbach DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1681370459; 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: in-reply-to:in-reply-to:references:references; bh=Gf8o/adbOI2wRHyAYHOuUl4w2xDShw502p6uq1yjW/o=; b=jd0nFk877ojN78H+xnoNZJ21TJY8IunD0mL0OMSkHT8cJWKHhKCmjsXX1SZDtHp6OLzOZp NICA8IzoOwv7zD95uzyVTkDBmzx18xtGUPeNehe1RiPxbCqrnHuNaiW1zgsUpZOsMhihpm 2ZTYF0YzDIuwhgmX+BstzaRDWE0w1WA+nM+mEIrhwpgeNgnbBSQiRjvCKEp3ygKClUMPlq K5uJftvEczJMAuN1U/U4sIGgzf/pEvTXBAg3Xk4/AMA7SzwSs2L6VQbv4jesLq2vYkX4iI /QHeBkApg8ydOjrkLzqp1rD0dWqlSlTfd8sFUwqs2iRqr3Oa6KaKh+3nb+OX6Q== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1681370459; 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: in-reply-to:in-reply-to:references:references; bh=Gf8o/adbOI2wRHyAYHOuUl4w2xDShw502p6uq1yjW/o=; b=55cEtF6OKAcYwqDBb/O/ndO9DLSWPvumJVkEmWH/bw0Mg3gePHry7BysvkfLRWfZsiUbcp geJacF7BdpyxHGAQ== To: Jacob Keller , Jesse Brandeburg , Tony Nguyen Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Vinicius Costa Gomes , Ong Boon Leong , intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org Subject: Re: [PATCH net-next] igc: Avoid transmit queue timeout for XDP In-Reply-To: <1809a34d-dcf4-4b54-089a-a7be3f4c23e1@intel.com> References: <20230412073611.62942-1-kurt@linutronix.de> <1809a34d-dcf4-4b54-089a-a7be3f4c23e1@intel.com> Date: Thu, 13 Apr 2023 09:20:57 +0200 Message-ID: <874jpk2qp2.fsf@kurt> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed Apr 12 2023, Jacob Keller wrote: > On 4/12/2023 12:36 AM, Kurt Kanzenbach wrote: >> High XDP load triggers the netdev watchdog: >>=20 >> |NETDEV WATCHDOG: enp3s0 (igc): transmit queue 2 timed out >>=20 >> The reason is the Tx queue transmission start (txq->trans_start) is not = updated >> in XDP code path. Therefore, add it for all XDP transmission functions. >>=20 >> Signed-off-by: Kurt Kanzenbach > > For Intel, I only see this being done in igb, as 5337824f4dc4 ("net: > annotate accesses to queue->trans_start"). I see a few other drivers > also calling this. > > Is this a gap that other XDP implementations also need to fix? > > grepping for txq_trans_cond_update I see: > >> apm/xgene/xgene_enet_main.c >> 874: txq_trans_cond_update(txq); >>=20 >> engleder/tsnep_main.c >> 623: txq_trans_cond_update(tx_nq); >> 1660: txq_trans_cond_update(nq); >>=20 >> freescale/dpaa/dpaa_eth.c >> 2347: txq_trans_cond_update(txq); >> 2553: txq_trans_cond_update(txq); >>=20 >> ibm/ibmvnic.c >> 2485: txq_trans_cond_update(txq); >>=20 >> intel/igb/igb_main.c >> 2980: txq_trans_cond_update(nq); >> 3014: txq_trans_cond_update(nq); >>=20 >> stmicro/stmmac/stmmac_main.c >> 2428: txq_trans_cond_update(nq); >> 4808: txq_trans_cond_update(nq); >> 6436: txq_trans_cond_update(nq); >>=20 > > Is most driver's XDP implementation broken? There's also > netif_trans_update but this is called out as a legacy only function. Far > more drivers call this but I don't see either call or a direct update to > trans_start in many XDP implementations... > > Am I missing something or are a bunch of other XDP implementations also > wrong? > > The patch seems ok to me, assuming this is the correct way to fix things > and not something in the XDP path. AFAICT the netdev watchdog is only started when the device exposes ndo_tx_timeout callback (see __netdev_watchdog_up()). For igc this callback was introduced recently in 9b275176270e ("igc: Add ndo_tx_timeout support"). My guess, as soon as the net device has ndo_tx_timeout it needs to maintain trans_start for XDP? Thanks, Kurt --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJHBAEBCgAxFiEEvLm/ssjDfdPf21mSwZPR8qpGc4IFAmQ3rVkTHGt1cnRAbGlu dXRyb25peC5kZQAKCRDBk9HyqkZzgibTD/0S41/87v4PI039H0WiQE3mh+bEA9rP I8IbnifWL8hhJGedZBCucDwNuSsXADxiHrSLKVGdz0UjgFJExkMGrSEvBFrV0Zs4 MYuMTlw/wYTF4KN5YBYqkzCsIuzrl+yGdhtBDcuTaxl0YLzF6xUP7yALAtyZgY+1 +u15zKytCypI5FDB1VqfNiOc3kw6NtfvCxTZQwPuBC8ZP6jF+qrG0xI+ldnjnXl3 0qJyRQCdE7+cfY7/meuZRtipP6WLcOLjUofUnHVCnXmLituzWgY8ZS/nQA9yiEvU Wo9OdTcUmof8R7cLKcQZbtf4v97CtAy6oYbONUHPDePcmDJhAO92fvmGty0GQH32 oBfOVCy2fzJ9lf4rjOKRmXYauCVtGmZDTAFcQakN1T+PXYdZku9RTp06I+JTKhgh MPl7tyCYw4Vr576N9GLc928XIXB5WR1ADokAvgZ6zQtiVDKnM+az4MHmXfo4rHcG BXm2zu4zQrC/DkW8CsfjcdCaloa62OlxthfD5kCkvh/Ew70E+DCJSeQGfTr4Dxkg oO9GmxaVziXwOGuyYR4giygCHmNbPsSPK2uWRQ5VcTRjZwzYpV8Rv2NKy7ZHRsgk 7swx2IYnVijlnWri2S4rsMXxqR5QkfqdCmOTXlwWukWUE9i8JTo2/EX2kx2Z+/j3 FNJeiexMFBINug== =iqmd -----END PGP SIGNATURE----- --=-=-=--