DPDK-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Bruce Richardson" <bruce.richardson@intel.com>
Cc: <dev@dpdk.org>
Subject: RE: [PATCH] net/intel: do not bypass mbuf lib for mbuf fast-free
Date: Tue, 21 Apr 2026 12:44:56 +0200	[thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35F65803@smartserver.smartshare.dk> (raw)
In-Reply-To: <aedSxmC4gskM6mHM@bricha3-mobl1.ger.corp.intel.com>

> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Tuesday, 21 April 2026 12.35
> 
> On Sat, Apr 18, 2026 at 09:56:38AM +0000, Morten Brørup wrote:
> > Freeing mbufs directly into the mempool meant that mbuf
> instrumentation,
> > including mbuf history marking, was omitted.
> > The mbufs are now freed via the rte_mbuf_raw_free_bulk() function
> instead.
> >
> > Added a static_assert to ensure that type casting the array of struct
> > ci_tx_entry_vec to an array of rte_mbuf pointers remains sound.
> >
> > Performance note:
> > The (n & 31) condition was not removed.
> > For the default tx_rs_thresh value (32), the condition will be true.
> > And due to inlining, the rte_mbuf_raw_free_bulk() ends up in an
> > rte_memcpy(), where the optimizer takes advantage of knowing that the
> > lower bits are not set.
> > This should compensate somewhat for removing the handcoded
> optimization of
> > copying in chunks of 32 mbufs.
> >
> > Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
> > ---
> 
> Ran a very quick perf test using a couple of 100G ports, no regression
> seen with this patch, maybe even a slight perf bump. Therefore:
> 
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> Tested-by: Bruce Richardson <bruce.richardson@intel.com>
> 
> One comment inline below:
> 
> >  doc/guides/rel_notes/release_26_07.rst |  4 +++
> >  drivers/net/intel/common/tx.h          | 36 +++---------------------
> --
> >  2 files changed, 7 insertions(+), 33 deletions(-)
> >
> > diff --git a/doc/guides/rel_notes/release_26_07.rst
> b/doc/guides/rel_notes/release_26_07.rst
> > index 060b26ff61..9367d38b13 100644
> > --- a/doc/guides/rel_notes/release_26_07.rst
> > +++ b/doc/guides/rel_notes/release_26_07.rst
> > @@ -24,6 +24,10 @@ DPDK Release 26.07
> >  New Features
> >  ------------
> >
> > +* **Updated Intel common driver.**
> > +
> > +  * Added missing mbuf history marking to vectorized Tx path for
> MBUF_FAST_FREE.
> > +
> 
> I don't think this is a big enough change to require a release note
> update.
> It's really more of a bug fix. If you are ok with it, I'd like to drop
> this
> RN entry on apply of the patch?

OK with me.

> 
> >  .. This section should contain new features added in this release.
> >     Sample format:
> >
> > diff --git a/drivers/net/intel/common/tx.h
> b/drivers/net/intel/common/tx.h
> > index 283bd58d5d..4a201da83c 100644
> > --- a/drivers/net/intel/common/tx.h
> > +++ b/drivers/net/intel/common/tx.h
> > @@ -285,42 +285,12 @@ ci_tx_free_bufs_vec(struct ci_tx_queue *txq,
> ci_desc_done_fn desc_done, bool ctx
> >  			(txq->fast_free_mp = txep[0].mbuf->pool);
> >
> >  	if (mp != NULL && (n & 31) == 0) {
> > -		void **cache_objs;
> > -		struct rte_mempool_cache *cache =
> rte_mempool_default_cache(mp, rte_lcore_id());
> > -
> > -		if (cache == NULL)
> > -			goto normal;
> > -
> > -		cache_objs = &cache->objs[cache->len];
> > -
> > -		if (n > RTE_MEMPOOL_CACHE_MAX_SIZE) {
> > -			rte_mempool_ops_enqueue_bulk(mp, (void *)txep, n);
> > -			goto done;
> > -		}
> > -
> > -		/* The cache follows the following algorithm
> > -		 *   1. Add the objects to the cache
> > -		 *   2. Anything greater than the cache min value (if it
> > -		 *   crosses the cache flush threshold) is flushed to the
> ring.
> > -		 */
> > -		/* Add elements back into the cache */
> > -		uint32_t copied = 0;
> > -		/* n is multiple of 32 */
> > -		while (copied < n) {
> > -			memcpy(&cache_objs[copied], &txep[copied], 32 *
> sizeof(void *));
> > -			copied += 32;
> > -		}
> > -		cache->len += n;
> > -
> > -		if (cache->len >= cache->flushthresh) {
> > -			rte_mempool_ops_enqueue_bulk(mp, &cache->objs[cache-
> >size],
> > -					cache->len - cache->size);
> > -			cache->len = cache->size;
> > -		}
> > +		static_assert(sizeof(*txep) == sizeof(struct rte_mbuf *),
> > +				"txep array is not similar to an array of
> rte_mbuf pointers");
> > +		rte_mbuf_raw_free_bulk(mp, (void *)txep, n);
> >  		goto done;
> >  	}
> >
> > -normal:
> >  	m = rte_pktmbuf_prefree_seg(txep[0].mbuf);
> >  	if (likely(m)) {
> >  		free[0] = m;
> > --
> > 2.43.0
> >

  reply	other threads:[~2026-04-21 10:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-18  9:56 [PATCH] net/intel: do not bypass mbuf lib for mbuf fast-free Morten Brørup
2026-04-19  6:29 ` Morten Brørup
2026-04-21 10:34 ` Bruce Richardson
2026-04-21 10:44   ` Morten Brørup [this message]
2026-04-21 11:00   ` Bruce Richardson

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=98CBD80474FA8B44BF855DF32C47DC35F65803@smartserver.smartshare.dk \
    --to=mb@smartsharesystems.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    /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