DPDK-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: "Loftus, Ciara" <ciara.loftus@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"mb@smartsharesystems.com" <mb@smartsharesystems.com>
Subject: Re: [PATCH v3] net/intel: optimize for fast-free hint
Date: Tue, 2 Jun 2026 16:36:57 +0100	[thread overview]
Message-ID: <ah74mTpWEtIUACtG@bricha3-mobl1.ger.corp.intel.com> (raw)
In-Reply-To: <DM3PPF7D18F34A17BA228196DB8843D7D6F8E092@DM3PPF7D18F34A1.namprd11.prod.outlook.com>

On Thu, May 28, 2026 at 02:23:00PM +0100, Loftus, Ciara wrote:
> > Subject: [PATCH v3] net/intel: optimize for fast-free hint
> > 
> 
> snip
> 
> > diff --git a/drivers/net/intel/common/tx_scalar.h
> > b/drivers/net/intel/common/tx_scalar.h
> > index 9fcd2e4733..d27df34dfa 100644
> > --- a/drivers/net/intel/common/tx_scalar.h
> > +++ b/drivers/net/intel/common/tx_scalar.h
> > @@ -197,16 +197,64 @@ ci_tx_xmit_cleanup(struct ci_tx_queue *txq)
> >  	const uint16_t rs_idx = (last_desc_cleaned == nb_tx_desc - 1) ?
> >  			0 :
> >  			(last_desc_cleaned + 1) >> txq->log2_rs_thresh;
> > -	uint16_t desc_to_clean_to = (rs_idx << txq->log2_rs_thresh) + (txq-
> > >tx_rs_thresh - 1);
> > +	const uint16_t dd_idx = txq->rs_last_id[rs_idx];
> > +	const uint16_t first_to_clean = rs_idx << txq->log2_rs_thresh;
> > 
> > -	/* Check if descriptor is done  */
> > -	if ((txd[txq->rs_last_id[rs_idx]].cmd_type_offset_bsz &
> > -			rte_cpu_to_le_64(CI_TXD_QW1_DTYPE_M)) !=
> > -
> > 	rte_cpu_to_le_64(CI_TX_DESC_DTYPE_DESC_DONE))
> > +	/* Check if descriptor is done - all drivers use 0xF as done value in bits
> > 3:0 */
> > +	if ((txd[dd_idx].cmd_type_offset_bsz &
> > rte_cpu_to_le_64(CI_TXD_QW1_DTYPE_M)) !=
> > +			rte_cpu_to_le_64(CI_TX_DESC_DTYPE_DESC_DONE))
> > +		/* Descriptor not yet processed by hardware */
> >  		return -1;
> > 
> > +	/* DD bit is set, descriptors are done. Now free the mbufs. */
> > +	/* Note: nb_tx_desc is guaranteed to be a multiple of tx_rs_thresh,
> > +	 * validated during queue setup. This means cleanup never wraps
> > around
> > +	 * the ring within a single burst (e.g., ring=256, rs_thresh=32 gives
> > +	 * bursts of 0-31, 32-63, ..., 224-255).
> > +	 */
> > +	const uint16_t nb_to_clean = txq->tx_rs_thresh;
> > +	struct ci_tx_entry *sw_ring = txq->sw_ring;
> > +
> > +	/* fast_free_mp is NULL only when the fast free is disabled*/
> > +	if (txq->fast_free_mp != NULL) {
> > +		/* FAST_FREE path: mbufs are already reset, just return to
> > pool */
> > +		struct rte_mbuf *free[CI_TX_MAX_FREE_BUF_SZ];
> > +		uint16_t nb_free = 0;
> > +
> > +		/* Get cached mempool pointer, or cache it on first use */
> > +		struct rte_mempool *mp =
> > +			likely(txq->fast_free_mp != (void *)UINTPTR_MAX) ?
> > +			txq->fast_free_mp :
> > +			(txq->fast_free_mp = sw_ring[dd_idx].mbuf->pool);
> 
> Is the mbuf you are dereferencing here guaranteed to be non NULL?
> 
Good point. It almost certainly is, but checking through the logic of the
code, the one possible error condition is where we have the last segment of
the packet being a large segment using TSO which is to be split across
multiple data descriptors. In that case (only) the mbuf pointer can be
NULL. In all other cases, it should be valid, because the DD bit can only
be set on a data descriptor.

Rather than trying to fix that issue here on cleanup, I think the better
solution is to adjust the large segment handling so that the last
descriptor of the segment, rather than the first, has the mbuf pointer.
That way we can always know that the descriptor that has DD set on it will
have a valid mbuf. Will implement this as a separate patch in v4.

/Bruce

  reply	other threads:[~2026-06-02 15:37 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-15 11:06 mbuf fast-free requirements analysis Morten Brørup
2025-12-15 11:46 ` Bruce Richardson
2026-01-14 15:31   ` Morten Brørup
2026-01-14 16:36     ` Bruce Richardson
2026-01-14 18:05       ` Morten Brørup
2026-01-15  8:46         ` Bruce Richardson
2026-01-15  9:04           ` Morten Brørup
2026-01-23 11:20     ` [PATCH] net/intel: optimize for fast-free hint Bruce Richardson
2026-01-23 12:05       ` Morten Brørup
2026-01-23 12:09         ` Bruce Richardson
2026-01-23 12:27           ` Morten Brørup
2026-01-23 12:53             ` Bruce Richardson
2026-01-23 13:06               ` Morten Brørup
2026-04-08 13:25       ` [PATCH v2] " Bruce Richardson
2026-04-08 19:27         ` Morten Brørup
2026-05-19 11:01           ` Bruce Richardson
2026-05-19 11:06       ` [PATCH v3] " Bruce Richardson
2026-05-28 13:23         ` Loftus, Ciara
2026-06-02 15:36           ` Bruce Richardson [this message]
2026-06-02 15:45       ` [PATCH v4 0/2] " Bruce Richardson
2026-06-02 15:45         ` [PATCH v4 1/2] net/intel: write mbuf for last Tx desc of segment Bruce Richardson
2026-06-03 14:21           ` Loftus, Ciara
2026-06-02 15:45         ` [PATCH v4 2/2] net/intel: optimize for fast-free hint Bruce Richardson
2026-06-02 16:26         ` [PATCH v4 0/2] " Morten Brørup
2026-06-03 15:56           ` Bruce Richardson
2026-01-23 11:33     ` mbuf fast-free requirements analysis Bruce Richardson
2025-12-15 14:41 ` Konstantin Ananyev
2025-12-15 16:14   ` Morten Brørup
2025-12-19 17:08     ` Konstantin Ananyev
2025-12-20  7:33       ` Morten Brørup
2025-12-22 15:22         ` Konstantin Ananyev
2025-12-22 17:11           ` Morten Brørup
2025-12-22 17:43             ` Bruce Richardson
2026-01-13 14:48               ` Konstantin Ananyev
2026-01-13 16:07                 ` Stephen Hemminger
2026-01-14 17:01 ` Bruce Richardson
2026-01-14 17:31   ` Morten Brørup
2026-01-14 17:45     ` 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=ah74mTpWEtIUACtG@bricha3-mobl1.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=ciara.loftus@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