Re: [PATCH net] net: thunderbolt: Count delivered packets in rx_packets and rx_bytes
Simon Horman <[email protected]>
| Newsgroups | org.kernel.vger.netdev,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On Sat, Aug 15, 2026 at 10:21:52AM +0000, Fan Ye via B4 Relay wrote: > From: Fan Ye <[email protected]> > > 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 <[email protected]> > --- > 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 <[email protected]>