macb1 checksum fixes - #7552
Open
nbuchwitz wants to merge 2 commits into
Open
Conversation
Frames that take the macb_pad_and_fcs() path are padded and get four FCS bytes appended, and the TX completion paths account the resulting skb->len. tx_bytes must exclude the FCS, and frames padded by the hardware are counted without the padding, so these frames are over-counted by the FCS and any padding added. Save the length as handed over by the stack and use it for the byte statistics. BQL keeps working on the padded skb->len, which netdev_tx_sent_queue() saw as well. Fixes: 653e92a ("net: macb: add support for padding and fcs computation") Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
The GEM transmit checksum engine inserts the raw one's complement result into the checksum field. When a UDP checksum computes to zero, RFC 768 requires 0xffff on the wire, zero means the sender generated no checksum. The engine sends 0x0000 instead, which turns off the integrity check for IPv4 and makes receivers drop the datagram for IPv6. This hits roughly one in 65536 UDP packets. Complete UDP checksums in software. The skb then continues with ip_summed cleared, so macb_pad_and_fcs() appends the FCS and the TX_NOCRC descriptor bit keeps the hardware from modifying the frame. TCP keeps the offload, a zero TCP checksum is valid there. One-step PTP sync packets stay on the hardware path because the MAC rewrites their timestamp during transmit and would invalidate a software checksum. The zero checksum case remains for those packets. Fixes: 85ff3d8 ("net/macb: add TX checksum offload feature") Link: raspberrypi#7550 Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
nbuchwitz
force-pushed
the
devel/macb-checksum
branch
from
August 13, 2026 08:58
eb3d0e3 to
ecebe6c
Compare
Contributor
|
Does this force a software checksum for all packets? Can't it just fix up the special case? (And it's @pelwell) |
Contributor
Author
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. |
Contributor
|
Perhaps someone else could pitch in - I'm OoO for a while |
Contributor
Author
|
Enjoy, well deserved! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.