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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 4F7EFC5B572 for ; Fri, 14 Aug 2026 00:22:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To: From:Date:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=BTbUb3MX/t95fArHVnY9sL9y9W4mR5L77BDPM1oB7qQ=; b=B2aQzp18ewWpnnxQ1lvSUgWkkg zNNMLqae+W7UeVMdNQv7HyfG6Mt0+pYWGhwPK5jiTwetA37Fbg3KlG8STjFn9FD5hRQaFv742BPAz aZqGAqBOTS3VDrqYHuIuox3F4/6uR3kqIly+DyTvXdk3Dd9h0pG4hf2MYNdzdgRt/huoDnCsTB1U5 NKqP1z5R60lr763lmmRufJ7DIJttMlYVmRC8caZ/WF9P1DBALVp/RzI7qhghKpxVUjbBomIBHDC3J utZjiQ8lPHM00fYTgmDhebVKM48TDAoQHQtOXS8GIP7QPugda+D33zK7fUuOWVp8T5/hUX3gytH3d sVF0a2LQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wufgO-00000001lfU-2XAF; Fri, 14 Aug 2026 00:22:00 +0000 Received: from sea.source.kernel.org ([172.234.252.31]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wufgN-00000001lfO-0Ubw for linux-arm-kernel@lists.infradead.org; Fri, 14 Aug 2026 00:21:59 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 1A15F4191C; Fri, 14 Aug 2026 00:21:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9CB151F000E9; Fri, 14 Aug 2026 00:21:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786666918; bh=BTbUb3MX/t95fArHVnY9sL9y9W4mR5L77BDPM1oB7qQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=lFf6wNbIA/mnWUXJe1uFMLtsfn4y468vV0gNvVxUpMCSEGA8fHpTo6txg1pamW6ry b9HPp+slKWH+Z5KjcerTk1o5WOX0NqWhvsTtB1HYxFV2+bLTmjxWILX53YV5etkJm8 vA2KPQwTj5TPDteIuY7PWWwxDOFIUJq2ZUGUUbw172YVxXzhsLrFRfQtHeylQMuBoe U4BNYfhuyYYCjbzgzal6NktxNcWYtEZ5sQl+acgvhqno2t5YtDki7jE2HzOXWouzMC HcQ1R10LRncJKDLDcWmVpdAX4ihrWabBwsmI8VPeyoIJYM/TzXs+t+inKH/I6GTy4s vqn/OguKOFv4Q== Date: Thu, 13 Aug 2026 17:21:56 -0700 From: Jakub Kicinski To: Lorenzo Bianconi Cc: Maxime Chevallier , Andrew Lunn , "David S. Miller" , Eric Dumazet , Paolo Abeni , Maxime Coquelin , Alexandre Torgue , netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH net-next v2] net: stmmac: improve TSO/GSO queue selection Message-ID: <20260813172156.0243cb7a@kernel.org> In-Reply-To: References: <20260808-stmmac_select_queue-tso-fix-v2-1-67175b29772e@oss.qualcomm.com> <20260812161038.5602eac9@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 13 Aug 2026 22:36:29 +0200 Lorenzo Bianconi wrote: > On Aug 12, Jakub Kicinski wrote: > > On Wed, 12 Aug 2026 18:11:31 +0200 Lorenzo Bianconi wrote: =20 > > > please drop this version, I will post v3 to fix some pending issues. = =20 > >=20 > > FTR Russell was trying to fix TSO in this driver too, before giving up > > (on us?). The direction he was following of clearing the TSO caps in > > ndo_features_check and letting the stack GSO instead of all the weird > > hacks this driver has seemed much more sane. But maybe I'm missing > > something TBS specific here =20 >=20 > thx for the pointers. I reviewed Russell's commits and I guess we have two > options here: >=20 > - manages all the TSO/GSO checks in ndo_features_check() (stmmac_features= _check()) > and disable TSO/GSO if the selected queue does not support checksum off= load > or it has TBS enabled. In this case I guess we can drop ndo_select_queu= e() > callback completely (it does not make sense to me to always use queue 0= for > TSO/GSO packets, e.g. it does not allow proper mqprio offload). > Please note this approach would introduce some performance regressions = with > respect of the previous implementation. > - implements TSO/GSO checks in ndo_select_queue() callback > (stmmac_select_queue()) in order to keep TSO/GSO enabled if the selected > queue supports it and at the same time do not always use queue 0 for TS= O/GSO > packets (proper qdisc offload). Please note this is patch I am proposin= g. >=20 > What do you think? I don't know this driver, or how it's used. =46rom the commit message it sounds like "if the packet wants TSO and=20 the queue has a scheduler enabled - take the packet to another queue". Presumably you know why the TBS is enabled and whether the packet should or should not be going to that queue in the first place if you're sending the patch? What is the use case?