From: Rosen Penev <rosenp@gmail.com>
To: linuxppc-dev@lists.ozlabs.org
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Nicholas Piggin <npiggin@gmail.com>,
"Christophe Leroy (CS GROUP)" <chleroy@kernel.org>,
"Ritesh Harjani (IBM)" <ritesh.list@gmail.com>,
Shrikanth Hegde <sshegde@linux.ibm.com>,
Andrew Lunn <andrew@lunn.ch>,
Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Michael Stapelberg <michael@stapelberg.de>,
linux-kernel@vger.kernel.org (open list),
netdev@vger.kernel.org (open list:ETHERNET PHY LIBRARY)
Subject: [PATCH v3] powerpc/lib: prefetch ahead in __csum_partial()
Date: Wed, 14 Oct 2026 12:48:17 -0700 [thread overview]
Message-ID: <20261014194818.11640-1-rosenp@gmail.com> (raw)
__csum_partial() walks the buffer linearly and reads each cache line
exactly once. On cores without a hardware prefetcher, such as the 464FP
in the APM82181, every new line is therefore a demand miss that stalls
the loop. Packets received by non-coherent DMA are never in the cache,
so this is the common case for GRO checksum validation: when routing
TCP with GRO enabled on a Meraki MX60, __csum_partial() takes about 30%
of all cycles and is the top entry in the profile.
Issue a dcbt MAX_COPY_PREFETCH cache lines ahead in the main loop,
the same distance csum_partial_copy_generic() already uses. That is
128 bytes on the 44x. dcbt is only a hint and never faults, so
prefetching past the end of the buffer is harmless. Lines that are
already cached, for example when checksumming data the CPU just wrote,
are left untouched.
Measured on a Meraki MX60 (APM82181 at 800 MHz), single TCP stream
routed through a qca8k DSA switch, iperf3 median of 5. Only the dcbt
was toggled at runtime, in the same boot:
LAN->WAN WAN->LAN
Mbit/s csum cycles Mbit/s csum cycles
before 495 30.5% 439 27.2%
after 599 15.3% 520 13.7%
That is 58% less time spent in __csum_partial() per byte.
The prefetch distance was chosen with an earlier, slower driver
configuration (median of 3, Mbit/s):
distance LAN->WAN WAN->LAN
none 370 341
64 bytes 430 381
96 bytes 438 397
128 bytes 438 385
160 bytes 434 386
256 bytes 423 383
Prefetching the first lines before entering the loop made no
measurable difference and is not done.
Assisted-by: LLM
Signed-off-by: Rosen Penev <rosenp@gmail.com>
---
v3: use MAX_COPY_PREFETCH
v2: reword commit message and retest numbers.
arch/powerpc/lib/checksum_32.S | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/lib/checksum_32.S b/arch/powerpc/lib/checksum_32.S
index cd00b9bdd772..5bb872e9e68f 100644
--- a/arch/powerpc/lib/checksum_32.S
+++ b/arch/powerpc/lib/checksum_32.S
@@ -43,6 +43,7 @@ _GLOBAL(__csum_partial)
bdnz 2b
21: srwi. r6,r4,4 /* # blocks of 4 words to do */
beq 3f
+ li r9,MAX_COPY_PREFETCH*L1_CACHE_BYTES /* prefetch distance */
lwz r0,4(r3)
mtctr r6
lwz r6,8(r3)
@@ -52,7 +53,8 @@ _GLOBAL(__csum_partial)
lwzu r8,16(r3)
adde r5,r5,r7
bdz 23f
-22: lwz r0,4(r3)
+22: dcbt r3,r9
+ lwz r0,4(r3)
adde r5,r5,r8
lwz r6,8(r3)
adde r5,r5,r0
--
2.56.0
next reply other threads:[~2026-10-14 19:48 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-14 19:48 Rosen Penev [this message]
2026-10-14 19:48 ` [PATCH net v5] net: phy: marvell: keep WOL_EIE across interrupt reconfiguration Rosen Penev
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=20261014194818.11640-1-rosenp@gmail.com \
--to=rosenp@gmail.com \
--cc=andrew@lunn.ch \
--cc=chleroy@kernel.org \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=michael@stapelberg.de \
--cc=mpe@ellerman.id.au \
--cc=netdev@vger.kernel.org \
--cc=npiggin@gmail.com \
--cc=pabeni@redhat.com \
--cc=ritesh.list@gmail.com \
--cc=sshegde@linux.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox