All of lore.kernel.org
 help / color / mirror / Atom feed
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. 

  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.