From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Bruce Richardson" <bruce.richardson@intel.com>
Cc: <dev@dpdk.org>, "Konstantin Ananyev" <konstantin.ananyev@huawei.com>
Subject: RE: [PATCH] net/i40e: Fast release optimizations
Date: Thu, 11 Dec 2025 22:45:25 +0100 [thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35F655DC@smartserver.smartshare.dk> (raw)
In-Reply-To: <aTmnOwyh2u75Y3qp@bricha3-mobl1.ger.corp.intel.com>
> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Wednesday, 10 December 2025 18.01
>
> On Mon, Aug 11, 2025 at 02:47:17PM +0200, Morten Brørup wrote:
> > > From: Morten Brørup [mailto:mb@smartsharesystems.com]
> > > Sent: Tuesday, 24 June 2025 08.13
> > >
> > > When fast releasing mbufs, the mbufs are not accessed, so do not
> prefetch
> > > them.
> > > This saves a mbuf load operation for each fast released TX mbuf.
> > >
> > > When fast release of mbufs is enabled for a TX queue, cache the
> mbuf
> > > mempool pointer in the TX queue structure.
> > > This saves one mbuf load operation for each burst of fast released
> TX
> > > mbufs.
> > >
> > > The txep->mbuf pointer is not used after the mbuf has been freed,
> so do
> > > not reset the pointer.
> > > This saves a txep store operation for each TX mbuf freed.
> > >
> > > Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
> > > ---
> >
> > After further consideration, I think this patch should be split in
> two:
> > 1. Remove superfluous code: prefetching mbufs and resetting txep-
> >mbuf pointers.
> > 2. Cache the mbuf mempool pointer for FAST_FREE.
> >
> Hi Morten,
>
> any plans for a new version of this patch (split or otherwise)? This is
> popped up again on my list in patchwork and want to decide what to do
> with
> it for this release. :-)
>
> /Bruce
I'll give it another shot.
I took another look at it today, and it looks like the txep->mbuf (i.e. sw_ring[].mbuf) is used by other cleanup functions, so not NULL'ing it needs more detailed review.
Anyway, prefetching the mbufs is a complete waste for fast free, where the mbufs are not being accessed at all. So there's still something to gain here.
Also, my assumption that txq->offloads is hotter than txq->fast_free_mp seems not to hold either, so I'll play around with that too.
I'm considering sending a series of patches with very small steps, so the individual changes are easy to review.
-Morten
next prev parent reply other threads:[~2025-12-11 21:45 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-24 6:12 Morten Brørup
2025-06-25 10:47 ` Bruce Richardson
2025-06-25 11:15 ` Morten Brørup
2025-06-30 11:40 ` Konstantin Ananyev
2025-06-30 13:45 ` Morten Brørup
2025-06-30 16:06 ` Morten Brørup
2025-07-01 7:31 ` Morten Brørup
2025-07-01 8:16 ` Konstantin Ananyev
2025-07-01 9:09 ` Morten Brørup
2025-07-03 8:12 ` Konstantin Ananyev
2025-07-03 12:02 ` Morten Brørup
2025-08-11 12:47 ` Morten Brørup
2025-12-10 17:00 ` Bruce Richardson
2025-12-11 21:45 ` Morten Brørup [this message]
2025-12-12 11:16 ` 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=98CBD80474FA8B44BF855DF32C47DC35F655DC@smartserver.smartshare.dk \
--to=mb@smartsharesystems.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=konstantin.ananyev@huawei.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;
as well as URLs for NNTP newsgroup(s).