From: Stephen Hemminger <stephen@networkplumber.org>
To: "Morten Brørup" <mb@smartsharesystems.com>
Cc: <dev@dpdk.org>, "John W. Linville" <linville@tuxdriver.com>
Subject: Re: [RFC 4/4] net/af_packet: add VPP-style prefetching to receive path
Date: Mon, 2 Feb 2026 10:43:30 -0800 [thread overview]
Message-ID: <20260202104330.27156f31@phoenix.local> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35F656C7@smartserver.smartshare.dk>
On Thu, 29 Jan 2026 10:00:15 +0100
Morten Brørup <mb@smartsharesystems.com> wrote:
> > This and previous proposal to prefetch have no impact on performance.
> > Rolled a simple perf test and all three versions come out the same.
>
> Please be aware that many test cases are inadvertently designed in a way where mbufs unintendedly are hot in the cache, so prefetching does not provide the expected performance gain.
> E.g. when working on a newly allocated mbuf, the mbuf should be cold.
> But if it came from the mempool cache, and was recently worked on and then freed into the mempool cache, then it will be hot.
>
> > The bottleneck is not here, probably at system call and copies now.
>
> The most important bottleneck might be elsewhere.
> But this optimization might not be as irrelevant as the test results indicate.
>
> Anyway, I agree that dropping the patch (for now) makes sense.
I doubt pre-fetch will matter much in a driver like this because:
- on tx the data is still in cache since just setup by caller
- on rx the data is still in cache since kernel just copied
it into the buffer.
next prev parent reply other threads:[~2026-02-02 18:43 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-28 17:30 [RFC 0/4] net/af_packet: cleanups and optimizations Stephen Hemminger
2026-01-28 17:30 ` [RFC 1/4] net/af_packet: remove volatile from statistics Stephen Hemminger
2026-01-28 19:57 ` Scott Mitchell
2026-01-28 21:00 ` Stephen Hemminger
2026-02-02 7:02 ` Scott Mitchell
2026-02-02 17:34 ` Stephen Hemminger
2026-02-02 19:12 ` Scott Mitchell
2026-02-02 20:12 ` Stephen Hemminger
2026-01-28 17:30 ` [RFC 2/4] test: add test for af_packet Stephen Hemminger
2026-01-28 20:36 ` Scott Mitchell
2026-01-28 21:45 ` Stephen Hemminger
2026-01-28 17:30 ` [RFC 3/4] net/af_packet: fix indentation Stephen Hemminger
2026-01-28 17:30 ` [RFC 4/4] net/af_packet: add VPP-style prefetching to receive path Stephen Hemminger
2026-01-29 1:06 ` Stephen Hemminger
2026-01-29 9:00 ` Morten Brørup
2026-02-02 7:09 ` Scott Mitchell
2026-02-02 18:43 ` Stephen Hemminger [this message]
2026-02-03 7:31 ` Morten Brørup
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=20260202104330.27156f31@phoenix.local \
--to=stephen@networkplumber.org \
--cc=dev@dpdk.org \
--cc=linville@tuxdriver.com \
--cc=mb@smartsharesystems.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.