When a UDPv4 checksum computes to zero, RFC 768 wants 0xffff on the
wire, but the GEM sends the raw 0x0000, which receivers read as "no
checksum". Raspberry Pi confirmed in a simulation of the Cadence IP
that the engine skips the substitution for UDPv4. UDPv6 and TCP are
fine, and the IP changelog suggests all GEM revisions could be affected.
Reported and analyzed on the Raspberry Pi 5:
https://github.com/raspberrypi/linux/issues/7550

Patch 2 does UDPv4 checksums in software and lets the existing pad
and FCS path keep the hardware off the frame, UDPv6 and TCP keep
the offload. That path miscounts tx_bytes by the software FCS, so
patch 1 fixes the accounting first.

Tested on CM5. To reproduce, send bulk UDP to another host and capture
zero checksums on the receiving side:

  iperf3 -c <host> -u -b 200M -t 30
  tcpdump -ni <iface> 'src host <dut> and udp[6:2] == 0'

Without the fix a packet shows up every few seconds:

  12:46:20.002739 IP <dut>.36309 > <host>.5201: UDP, length 1448
  12:46:23.773968 IP <dut>.36309 > <host>.5201: UDP, length 1448
  12:46:40.227460 IP <dut>.36309 > <host>.5201: UDP, length 1448

With the fix the capture showed none.

Some numbers (udpgso_bench):
- 18-byte UDP throughput dropped by ~ 8%
- 256-byte UDP throughput dropped by ~ 10%
- MTU-sized UDP and UDP GSO were unchanged at the 116 MiB/s link limit

Unfortunately I don't see a cheaper fix, the zero only shows up after
computing the checksum, the MAC inserts it in flight, and AFAIU there is
no register or descriptor bit for the substitution.

I'd appreciate testing on other silicon.

Nicolai Buchwitz (2):
  net: macb: exclude software FCS from TX byte statistics
  net: macb: fix zero UDPv4 checksum on transmit

 drivers/net/ethernet/cadence/macb.h      |  3 +++
 drivers/net/ethernet/cadence/macb_main.c | 28 +++++++++++++++++++++-------
 2 files changed, 24 insertions(+), 7 deletions(-)

-- 
2.53.0

Hello Nicolai,

Am Mon, Aug 24, 2026 at 03:47:01PM +0200 schrieb Nicolai Buchwitz:
> When a UDPv4 checksum computes to zero, RFC 768 wants 0xffff on the
> wire, but the GEM sends the raw 0x0000, which receivers read as "no
> checksum". Raspberry Pi confirmed in a simulation of the Cadence IP
> that the engine skips the substitution for UDPv4. UDPv6 and TCP are
> fine, and the IP changelog suggests all GEM revisions could be affected.
> Reported and analyzed on the Raspberry Pi 5:
> https://github.com/raspberrypi/linux/issues/7550
> 
> Patch 2 does UDPv4 checksums in software and lets the existing pad
> and FCS path keep the hardware off the frame, UDPv6 and TCP keep
> the offload. That path miscounts tx_bytes by the software FCS, so
> patch 1 fixes the accounting first.
> 
> Tested on CM5. To reproduce, send bulk UDP to another host and capture
> zero checksums on the receiving side:
> 
>   iperf3 -c <host> -u -b 200M -t 30
>   tcpdump -ni <iface> 'src host <dut> and udp[6:2] == 0'
> 
> Without the fix a packet shows up every few seconds:
> 
>   12:46:20.002739 IP <dut>.36309 > <host>.5201: UDP, length 1448
>   12:46:23.773968 IP <dut>.36309 > <host>.5201: UDP, length 1448
>   12:46:40.227460 IP <dut>.36309 > <host>.5201: UDP, length 1448
> 
> With the fix the capture showed none.
> 
> Some numbers (udpgso_bench):
> - 18-byte UDP throughput dropped by ~ 8%
> - 256-byte UDP throughput dropped by ~ 10%
> - MTU-sized UDP and UDP GSO were unchanged at the 116 MiB/s link limit
> 
> Unfortunately I don't see a cheaper fix, the zero only shows up after
> computing the checksum, the MAC inserts it in flight, and AFAIU there is
> no register or descriptor bit for the substitution.
> 
> I'd appreciate testing on other silicon.

I tested without your patch on at91 sama5d2 (Cadence GEM rev
0x00020203), sam9x60 (Cadence MACB rev 0x0001010c), and sam9g20
(Cadence MACB rev 0x0001010c), and tried to reproduce the flaw (not
the fix).  Rewrote the Python reproducer suggested in that RPi github
issue in C, but iperf3 gave similar results:  tcpdump started as
suggested showed not a single wrong package!

However according to ethtool it seems at least the older MACB bases
hardware has no hardware checksumming here.  On sama5d2 (GEM, but no
Gigabit) I'm not sure if it is supposed to be done for UDP?  See:

    $ ethtool -k eth0 | grep sum
    rx-checksumming: on
    tx-checksumming: on
            tx-checksum-ipv4: off [fixed]
            tx-checksum-ip-generic: on
            tx-checksum-ipv6: off [fixed]
            tx-checksum-fcoe-crc: off [fixed]
            tx-checksum-sctp: off [fixed]
    tx-gre-csum-segmentation: off [fixed]
    tx-udp_tnl-csum-segmentation: off [fixed]
    tx-tunnel-remcsum-segmentation: off [fixed]
    esp-tx-csum-hw-offload: off [fixed]

On sam9x60 (MACB) there seems to be no hardware offloading at all:

    $ ethtool -k eth0 | grep sum
    rx-checksumming: off [fixed]
    tx-checksumming: off
            tx-checksum-ipv4: off [fixed]
            tx-checksum-ip-generic: off [fixed]
            tx-checksum-ipv6: off [fixed]
            tx-checksum-fcoe-crc: off [fixed]
            tx-checksum-sctp: off [fixed]
    tx-gre-csum-segmentation: off [fixed]
    tx-udp_tnl-csum-segmentation: off [fixed]
    tx-tunnel-remcsum-segmentation: off [fixed]
    esp-tx-csum-hw-offload: off [fixed]

How are those chips affected by your patch then?

> Nicolai Buchwitz (2):
>   net: macb: exclude software FCS from TX byte statistics
>   net: macb: fix zero UDPv4 checksum on transmit

That fix seems to be very generic and not specific to macb or gem nor
to any variant.  I'd suggest narrowing it down and testing on more
hardware.

Greets
Alex

> 
>  drivers/net/ethernet/cadence/macb.h      |  3 +++
>  drivers/net/ethernet/cadence/macb_main.c | 28 +++++++++++++++++++++-------
>  2 files changed, 24 insertions(+), 7 deletions(-)
> 
> -- 
> 2.53.0
>