From: Konstantin Ananyev <konstantin.ananyev@huawei.com>
To: "Morten Brørup" <mb@smartsharesystems.com>,
"Bruce Richardson" <bruce.richardson@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: RE: [PATCH] net/i40e: Fast release optimizations
Date: Thu, 3 Jul 2025 08:12:48 +0000 [thread overview]
Message-ID: <03b6263113f642828843b60878c811e6@huawei.com> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9FD67@smartserver.smartshare.dk>
> > I am talking about different thing:
> > I think with some extra effort driver can use (in some cases)
> > rte_mbuf_raw_free_bulk() even when RTE_ETH_TX_OFFLOAD_MBUF_FAST_FREE
> > is not specified.
> > Let say we can make txq->fast_free_mp[] an array with the same size as txq-
> > >txep[].
> > At tx_burst() when filling txep[] we can do pre_free() checks for that mbuf,
> > and in case of success store it's mempool pointer in corresponding txq-
> > >fast_free_mp[],
> > otherwise put NULL there.
> > Then at tx_free() we can scan fast_free_mp[] and invoke raw_free() for non-
> > NULL entries.
> > Again, for now it is just an idea probably worth to think about.
>
> Yes, that seems like an excellent idea, certainly worth considering!
>
> At tx_free(), the mbufs might be cold, so not accessing them at this point improves performance. (Which is also the point of my
> patch.)
Yes.
>
> At tx_burst(), the mbufs are read anyway (their information is written into the tx descriptors), so the mbufs are hot in the cache at
> this point.
Yes.
> Best case with your suggestion, rte_pktmbuf_prefree_seg() doesn't write the mbuf, so the performance cost of doing it at tx_burst()
> is extremely low.
Yes.
> Worst case with your suggestion, rte_pktmbuf_prefree_seg() does write the mbuf, so the mbuf write operation simply moves from
> tx_free() to tx_burst().
> However, in tx_burst(), the mbuf is already hot in the cache, so per transmitted mbuf, we get one load+store at tx_burst() instead of
> one load at tx_burst() + one load+store at tx_free().
I suppose you plan to invoke full rte_pktmbuf_prefree_seg() here?
Unfortunately, I don't think it is possible - for cases when refcnt > 1, we need to decrement refcnt only when we are ready to
release the mbuf. Otherwise we can end up with NIC HW reading from already released (and probably re-used) mbuf.
What we probably need is a lightweight version of rte_pktmbuf_prefree_seg() that would return not-NULL value only when
refcnt==1, and segment and not indirect mbuf or external memory attached.
Something like:
static __rte_always_inline struct rte_mbuf *
rte_pktmbuf_prefree_check(sconst truct rte_mbuf *m)
{
if (rte_mbuf_refcnt_read(m) == 1 && RTE_MBUF_DIRECT(m))
return m;
return NULL;
}
So at worst case (when such check will return NULL) we still need to do load+store at tx_free().
next prev parent reply other threads:[~2025-07-03 8:12 UTC|newest]
Thread overview: 11+ 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 [this message]
2025-07-03 12:02 ` 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=03b6263113f642828843b60878c811e6@huawei.com \
--to=konstantin.ananyev@huawei.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--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 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).