[PATCH net 0/2] net: macb: fix zero UDPv4 checksum on transmit

[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.

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