On Sat, Aug 15, 2026 at 10:21:52AM +0000, Fan Ye via B4 Relay wrote:
From: Fan Ye <redacted>
tbnet_poll() increments rx_packets once per received frame because that is
the NAPI work unit, and then adds the same number to stats.rx_packets. An
skb is handed to the stack only when the last frame of a packet arrives,
so once the MTU exceeds TBNET_MAX_PAYLOAD_SIZE the statistic reports
frames. tx_packets is bumped once per skb, so the two ends of a link
disagree: at MTU 65330 the receiver reports 16 times the packets its
sender sent.
rx_bytes has the matching problem: frames of a packet that is later
dropped mid-assembly are already accounted, so it does not correspond to
rx_packets as documented. Account for both where the packet is completed,
and leave the NAPI work counter alone.
Fixes: e69b6c02b4c3 ("net: Add support for networking over Thunderbolt cable")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Fan Ye <redacted>
---
Seen at MTU 65330 on an ASM4242 host-to-host link, where a packet is 16
frames. On the receiver rx_bytes/rx_packets came out at 4083.9, i.e.
TBNET_MAX_PAYLOAD_SIZE, and rx_packets ran 15.9x the IP layer's InReceives;
with the patch they are 65308.3 and 0.99. At the default MTU a packet fits
in one frame and the counters already agree, which is why this went
unnoticed.
Reviewed-by: Simon Horman <horms@kernel.org>