From: Simon Horman <horms@kernel.org>
To: fy15309206903@gmail.com
Cc: Mika Westerberg <westeri@kernel.org>,
Paolo Abeni <pabeni@redhat.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Andrew Lunn <andrew+netdev@lunn.ch>,
Eric Dumazet <edumazet@google.com>,
Yehezkel Bernat <YehezkelShB@gmail.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH net] net: thunderbolt: Count delivered packets in rx_packets and rx_bytes
Date: Tue, 18 Aug 2026 20:03:26 +0100 [thread overview]
Message-ID: <20260818190326.GI265046@horms.kernel.org> (raw)
In-Reply-To: <20260815-tbnet-rx-stats-v1-1-8da375c2cd09@gmail.com>
On Sat, Aug 15, 2026 at 10:21:52AM +0000, Fan Ye via B4 Relay wrote:
> From: Fan Ye <fy15309206903@gmail.com>
>
> 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 <fy15309206903@gmail.com>
> ---
> 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>
next prev parent reply other threads:[~2026-08-18 19:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-15 10:21 [PATCH net] net: thunderbolt: Count delivered packets in rx_packets and rx_bytes Fan Ye via B4 Relay
2026-08-15 10:21 ` Fan Ye
2026-08-18 19:03 ` Simon Horman [this message]
2026-08-19 6:08 ` Mika Westerberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260818190326.GI265046@horms.kernel.org \
--to=horms@kernel.org \
--cc=YehezkelShB@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=andriy.shevchenko@linux.intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=fy15309206903@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=westeri@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.