DPDK patches and discussions
 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>
Subject: Re: [PATCH] net/intel: ensure correct Rx path is selected
Date: Wed, 12 Nov 2025 16:05:14 +0000	[thread overview]
Message-ID: <aRSwOrzXJ8hf_fpz@bricha3-mobl1.ger.corp.intel.com> (raw)
In-Reply-To: <DM3PPF7D18F34A1AB3C04F36867D89420428ECCA@DM3PPF7D18F34A1.namprd11.prod.outlook.com>

On Wed, Nov 12, 2025 at 03:52:59PM +0000, Loftus, Ciara wrote:
> > 
> > On Wed, Nov 12, 2025 at 03:11:23PM +0000, Ciara Loftus wrote:
> > > The common rx path selection logic iterates through an array of
> > > candidate paths and selects the best fit for the requested features.
> > > Currently, in the event that two potential candidates are identified,
> > > the one with the fewer offloads (and thus less complex path) is
> > > selected. However this is not correct, because if the path with more
> > > offloads has a greater SIMD width, that should be chosen. This commit
> > > reworks the logic so that the number of offloads is only taken into
> > > consideration when choosing between two paths with the same SIMD
> > width.
> > >
> > > Since the paths arrays are ordered from lowest SIMD width to highest,
> > > and vector paths tend to have fewer offloads enabled than scalar paths,
> > > "new" candidate paths with greater SIMDs widths tended to have fewer or
> > > equal offloads than the "current" candidate paths and thus were
> > > correctly accepted as the best candidate. For this reason the incorrect
> > > logic did not cause any incorrect path selections in practise.
> > >
> > > Fixes: 9d99641d80a0 ("net/intel: introduce infrastructure for Rx path
> > selection")
> > >
> > > Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
> > > ---
> > 
> > Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> > 
> > But see one comment inline below.
> > 
> > >  drivers/net/intel/common/rx.h | 7 +++++--
> > >  1 file changed, 5 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/net/intel/common/rx.h b/drivers/net/intel/common/rx.h
> > > index 5012e4fced..9fa3cdc64d 100644
> > > --- a/drivers/net/intel/common/rx.h
> > > +++ b/drivers/net/intel/common/rx.h
> > > @@ -300,8 +300,11 @@ ci_rx_path_select(struct ci_rx_path_features
> > req_features,
> > >  			/* Do not select paths with lower SIMD width than the
> > current path. */
> > >  			if (path_features->simd_width < current_features-
> > >simd_width)
> > >  				continue;
> > > -			/* Do not select paths with more offloads enabled
> > than the current path. */
> > > -			if (rte_popcount32(path_features->rx_offloads) >
> > > +			/* Do not select paths with more offloads enabled
> > than the current path if
> > > +			 * the SIMD widths are the same.
> > > +			 */
> > > +			if (path_features->simd_width == current_features-
> > >simd_width &&
> > > +					rte_popcount32(path_features-
> > >rx_offloads) >
> > >  					rte_popcount32(current_features-
> > >rx_offloads))
> > >  				continue;
> > 
> > The logic is correct, but reviewing this in isolation is a little confusing
> > because of the naming. Normally "current" implies the item we are currently
> > checking, so I assumed that path was the currently selected path, but it's
> > not. The roles are actually reversed, and "path" is the one being checked,
> > and current is the chosen one.
> > 
> > A simple fix that I think would help readability is to rename "current" to
> > "chosen_path". We could also rename "path" to "curr_path" in that case, but
> > I think it's unnecessary, as "chosen_path" and "path" should be relatively
> > clear.
> > 
> > What do you think?
> 
> +1 definitely agree the naming could be improved. I'll submit a follow-on patch.
> 
I'll take this as-is so, and you can base the follow-on on top of this.

  reply	other threads:[~2025-11-12 16:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-12 15:11 Ciara Loftus
2025-11-12 15:47 ` Bruce Richardson
2025-11-12 15:52   ` Loftus, Ciara
2025-11-12 16:05     ` Bruce Richardson [this message]
2025-11-12 16:35     ` 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=aRSwOrzXJ8hf_fpz@bricha3-mobl1.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=ciara.loftus@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;
as well as URLs for NNTP newsgroup(s).