From: Jakub Kicinski <kuba@kernel.org>
To: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: linux-usb@vger.kernel.org, netdev@vger.kernel.org,
Yehezkel Bernat <YehezkelShB@gmail.com>,
Lukas Wunner <lukas@wunner.de>,
Andreas Noever <andreas.noever@gmail.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S . Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>
Subject: Re: [PATCH 2/2] net: thunderbolt: Update ring indices only after all frames are queued
Date: Sat, 5 Sep 2026 13:57:02 -0700 [thread overview]
Message-ID: <20260905135702.1af66dde@kernel.org> (raw)
In-Reply-To: <20260902082128.1148463-3-mika.westerberg@linux.intel.com>
On Wed, 2 Sep 2026 10:21:28 +0200 Mika Westerberg wrote:
> Take advantage of the new API and update the ring producer/consumer
> indices only after the frames have been queued. This reduces the number
> of doorbell register writes from one per frame to one per batch.
>
> Measured using iperf3 over a Thunderbolt/USB4 net connection between
> Arrow Lake and Panther Lake systems (average of three runs):
>
> before after
> ~14.3 Gbit/s ~15.3 Gbit/s
Acked-by: Jakub Kicinski <kuba@kernel.org>
but Clashiko (sort of) hints at lack of proper handling of transient
memory allocation failures. Indeed the NAPI path seems to call
tbnet_alloc_rx_buffers() which flushes the ring completely on
any sign of trouble. (a) aren't we freeing buffers already handed
to HW; (b) if we flush Rx free list and there's no Tx won't the driver
wedge Rx and never schedule NAPI?
I'd suggest fixing that first before making any optimizations :S
next prev parent reply other threads:[~2026-09-05 20:57 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 8:21 [PATCH 0/2] thunderbolt / net: Allow batching of descriptors Mika Westerberg
2026-09-02 8:21 ` [PATCH 1/2] thunderbolt: " Mika Westerberg
2026-09-02 8:21 ` [PATCH 2/2] net: thunderbolt: Update ring indices only after all frames are queued Mika Westerberg
2026-09-05 20:57 ` Jakub Kicinski [this message]
2026-09-07 5:53 ` 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=20260905135702.1af66dde@kernel.org \
--to=kuba@kernel.org \
--cc=YehezkelShB@gmail.com \
--cc=andreas.noever@gmail.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=linux-usb@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mika.westerberg@linux.intel.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/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.