Skip to content

macb1 checksum fixes - #7552

Open
nbuchwitz wants to merge 2 commits into
raspberrypi:rpi-6.18.yfrom
nbuchwitz:devel/macb-checksum
Open

macb1 checksum fixes#7552
nbuchwitz wants to merge 2 commits into
raspberrypi:rpi-6.18.yfrom
nbuchwitz:devel/macb-checksum

Conversation

@nbuchwitz

Copy link
Copy Markdown
Contributor

fe4dd47 is a candidate for fixing #7550. The other patch fixes a stats issue and i plan to submit it in the same series upstream once I got confirmation that it fixes the issue

@pellwell, can you please trigger the builds? Thanks.

@pelwell

pelwell commented Aug 13, 2026

Copy link
Copy Markdown
Contributor

Does this force a software checksum for all packets? Can't it just fix up the special case? (And it's @pelwell)

@nbuchwitz

Copy link
Copy Markdown
Contributor Author

Does this force a software checksum for all packets? Can't it just fix up the special case? (And it's @pelwell)

No, UDP only. Fixing up the special case would mean computing the full checksum in software anyway, and AFAIU the hardware inserts the value in flight, so the driver never sees it.

I'll dig through the public AT91 / Zynq docs anyway, maybe there's a useful register after all. If you have access to ressources, pointers are welcome.

@pelwell

pelwell commented Aug 13, 2026

Copy link
Copy Markdown
Contributor

Perhaps someone else could pitch in - I'm OoO for a while

@nbuchwitz

Copy link
Copy Markdown
Contributor Author

Enjoy, well deserved!

Frames going through macb_pad_and_fcs() get padded and four FCS
bytes appended, and TX completion then accounts the grown skb->len.
tx_bytes is supposed to exclude the FCS, and frames padded by the
hardware are counted without the padding anyway, so these frames
show up too large in the statistics.

Remember the length the stack handed over and use that for the byte
counters. BQL stays on the padded skb->len that
netdev_tx_sent_queue() saw.

Fixes: 653e92a ("net: macb: add support for padding and fcs computation")
Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
@nbuchwitz
nbuchwitz force-pushed the devel/macb-checksum branch from ecebe6c to b891cc5 Compare August 20, 2026 07:59
The GEM checksum engine writes its raw result into the UDP checksum
field, so a UDPv4 checksum that computes to zero goes out as 0x0000.
RFC 768 requires:

  If the computed checksum is zero, it is transmitted as all ones
  (the equivalent in one's complement arithmetic). An all zero
  transmitted checksum value means that the transmitter generated
  no checksum (for debugging or for higher level protocols that
  don't care).

So these packets lose their integrity check and peers treat
them as sent without a checksum. Raspberry Pi confirmed in a
simulation of the Cadence IP [1] that the engine skips the final
substitution exactly for UDP over IPv4. UDPv6 and TCP come out
correct. The IP changelog shows no related change, so probably all
GEM revisions have the same bug.

Clear the checksum offload features for UDPv4 frames in
macb_features_check(), the core then completes the checksum in
software before handing the frame over. With ip_summed cleared,
macb_pad_and_fcs() appends the FCS and the TX_NOCRC descriptor bit
keeps the hardware off the frame. TCP and UDPv6 keep the offload.

One-step PTP sync packets keep the hardware path because the MAC
rewrites their timestamp during transmit, which would invalidate a
software checksum. Leave their existing checksum handling unchanged.

[1] raspberrypi#7550 (comment)

Fixes: 85ff3d8 ("net/macb: add TX checksum offload feature")
Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
@nbuchwitz
nbuchwitz force-pushed the devel/macb-checksum branch from b891cc5 to bbde467 Compare August 20, 2026 10:41
@P33M

P33M commented Aug 20, 2026

Copy link
Copy Markdown
Contributor

I've re-run workflows. Checkpatch has a single complaint, otherwise it's available for testing via rpi-update pulls/7552.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants