From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [78.32.30.218]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B7C2C376BCD for ; Wed, 1 Apr 2026 07:21:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=78.32.30.218 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775028064; cv=none; b=MTS5eYVoLKqpCvDLZX0ypRP6Ws8LyQK8nUpSR1GkGAr4Q2ysANH1d97WMBRB5yOhhGOZNCqeq9SSiMIdeypW0PRRRNxNH48eDSfAOhEICz8ceeeUJAs7f0LTjafLb5zcBSrFU6r7CAcPkK4oZvzWFPSLDjN1Qnahq/nhMgT4XdY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775028064; c=relaxed/simple; bh=FkZFVWQ7tfS09KSgH/klLnl0AkMyAP8/VQ+vu7LyRZA=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition; b=ZXWm2n+0tOFaMrysqd4HM7AU8Gn2pun3ebsEIryC4oZMKJoi93ydDplsPdJjpgC5mbUZwqfE+yZZ9E8z0JBo++i01lYxJnFT+PMQ+evZCC2N7HtqBqZevFTt8ghcsNhy4zlujU1FwQfuVXMQnc+K6eeR/sma3iTLKqghgcKzR0g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=armlinux.org.uk; spf=none smtp.mailfrom=armlinux.org.uk; dkim=pass (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b=LKFiCl0R; arc=none smtp.client-ip=78.32.30.218 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=armlinux.org.uk Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=armlinux.org.uk Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=armlinux.org.uk header.i=@armlinux.org.uk header.b="LKFiCl0R" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:Content-Type:MIME-Version: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=dtZ756YY08U7bg9gCLlbHxheqzmQ87Emq5OyGQIx0cI=; b=LKFiCl0RCjhzJ3C+P5IS8FxFBb 3BHkBjOpVXcISPhGwNG5h60PeNLqYYn9vKChFdm4c6MLX0tdzHkrNlHVb2hvz+orK1b74B1MhxJdU 7i9Sm1uXrovvajmGSMAa5BvNlXfJk619PVxp5PfPkq4duZtjBKRxF7EWWrwADc6XK4ZykcLSCAhjm iMpBsDrjqXuwa+6EZjxqlh849Vm1cXwP8NA7ES/MTyxPsLqZQt1MRqHIJtYORUUYxbxO9gXc++R5j tgXlSJ81IL/dzjic9fnGN/f8hFfKZ6BEaoV0if/9PeTQbVfeEss3GupRLcsdfbtpRsX1+wgwFSxIW xllbjzZw==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:48410) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1w7psl-000000002fC-40Ef; Wed, 01 Apr 2026 08:20:56 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.98.2) (envelope-from ) id 1w7psi-000000004be-2FE0; Wed, 01 Apr 2026 08:20:52 +0100 Date: Wed, 1 Apr 2026 08:20:52 +0100 From: "Russell King (Oracle)" To: Andrew Lunn Cc: Alexandre Torgue , Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , linux-arm-kernel@lists.infradead.org, linux-stm32@st-md-mailman.stormreply.com, netdev@vger.kernel.org, Ong Boon Leong , Paolo Abeni Subject: [PATCH net-next v2 00/14] net: stmmac: TSO fixes/cleanups Message-ID: Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: Russell King (Oracle) This is a more refined version of the previous patch series fixing and cleaning up the TSO code. I'm not sure whether "TSO" or "GSO" should be used to describe this feature - although it primarily handles TCP, dwmac4 appears to also be able to handle UDP. In essence, this series adds a .ndo_features_check() method to handle whether TSO/GSO can be used for a particular skbuff - checking which queue the skbuff is destined for and whether that has TBS available which precludes TSO being enabled on that channel. I'm also adding a check that the header is smaller than 1024 bytes, as documented in those sources which have TSO support - this is due to the hardware buffering the header in "TSO memory" which I guess is limited to 1KiB. I expect this test never to trigger, but if the headers ever exceed that size, the hardware will likely fail. While IPv4 headers are unlikely to be anywhere near this, there is nothing in the protocol which prevents IPv6 headers up to 64KiB. As we now have a .ndo_features_check() method, I'm moving the VLAN insertion for TSO packets into core code by unpublishing the VLAN insertion features when we use TSO. Another move is for checksumming, which is required for TSO, but stmmac's requirements for offloading checksums are more strict - and this seems to be a bug in the TSO path. I've changed the hardware initialisation to always enable TSO support on the channels even if the user requests TSO/GSO to be disabled - this fixes another issue as pointed out by Jakub in a previous review. I'm moving the setup of the GSO features, cleaning those up, and adding a warning if platform glue requests this to be enabled but the hardware has no support. Hopefully this will never trigger if everyone got the STMMAC_FLAG_TSO_EN flag correct. Also adding a check for TxPBL value. Finally, moving the "TSO supported" message to the new stmmac_set_gso_features() function so keep all this TSO stuff together. drivers/net/ethernet/stmicro/stmmac/stmmac.h | 3 +- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 214 +++++++++++++++------- 2 files changed, 150 insertions(+), 67 deletions(-) -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!