[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aKV0FF4FFARJNvZu@shell.armlinux.org.uk>
Date: Wed, 20 Aug 2025 08:07:00 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Oleksij Rempel <o.rempel@...gutronix.de>
Cc: Andrew Lunn <andrew+netdev@...n.ch>,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
Jose Abreu <joabreu@...opsys.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Maxime Coquelin <mcoquelin.stm32@...il.com>, kernel@...gutronix.de,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
Simon Horman <horms@...nel.org>,
Søren Andersen <san@...v.dk>
Subject: Re: [PATCH net-next v1 0/3] stmmac: stop silently dropping bad
checksum packets
On Mon, Aug 18, 2025 at 11:02:14AM +0200, Oleksij Rempel wrote:
> Hi all,
>
> this series reworks how stmmac handles receive checksum offload
> (CoE) errors on dwmac4.
>
> At present, when CoE is enabled, the hardware silently discards any
> frame that fails checksum validation. These packets never reach the
> driver and are not accounted in the generic drop statistics. They are
> only visible in the stmmac-specific counters as "payload error" or
> "header error" packets, which makes it harder to debug or monitor
> network issues.
FYI, there are counters at 0x214 and 0x228 that indicate header
problems, including checksum failures. There are also counters
at 0x234, 0x23c, 0x244 that count udp, tcp and icmp checksum
errors.
So, the hardware does keep statistics. Maybe we should make use
of those rather than the approach in this series?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
Powered by blists - more mailing lists