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]>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.