Re: [PATCH v2 12/15] net/intel: introduce infrastructure for Rx path selection

[Bruce Richardson <bruce.richardson@intel.com>]

On Thu, Aug 14, 2025 at 02:35:34PM +0100, Loftus, Ciara wrote:
> > 
> > On Thu, Aug 07, 2025 at 12:39:46PM +0000, Ciara Loftus wrote:
> > > The code for determining which Rx path to select during initialisation
> > > has become complicated in many intel drivers due to the amount of
> > > different paths and features available within each path. This commit
> > > aims to simplify and genericize the path selection logic.
> > >
> > > The following information about each Rx burst function is stored and
> > > used by the new common function to select the appropriate Rx path:
> > > - Rx Offloads
> > > - SIMD bitwidth
> > > - Flexible RXD usage
> > > - Bulk alloc function
> > > - Scattered function
> > > ---
> > > v2:
> > > * renamed various items from "burst" to "path"
> > > * added missing doxygen comments
> > > * attempted to improve the logic in the select function around the bulk
> > >  alloc feature
> > >
> > > Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
> > 
> > Two comments inline below.
> > 
> > Acked-by: Bruce Richardson <bruce.richardson@intel.com>
> > 
> > 
> > > ---
> > >  drivers/net/intel/common/rx.h | 103
> > ++++++++++++++++++++++++++++++++++
> > >  1 file changed, 103 insertions(+)
> > >
> > > diff --git a/drivers/net/intel/common/rx.h b/drivers/net/intel/common/rx.h
> > > index 70b597e8dc..6d134622e6 100644
> > > --- a/drivers/net/intel/common/rx.h
> > > +++ b/drivers/net/intel/common/rx.h
> > > @@ -10,6 +10,7 @@
> > >  #include <unistd.h>
> > >  #include <rte_mbuf.h>
> > >  #include <rte_ethdev.h>
> > > +#include <rte_vect.h>
> > >
> > >  #include "desc.h"
> > >
> > > @@ -125,6 +126,26 @@ struct ci_rx_queue {
> > >  	};
> > >  };
> > >
> > > +#define CI_RX_PATH_SCATTERED 1
> > > +#define CI_RX_PATH_FLEX_DESC 1
> > > +#define CI_RX_PATH_BULK_ALLOC 1
> > > +#define CI_RX_PATH_DISABLED 1
> > > +
> > 
> > Do we need these defines? They are not used in this patch anyway. With the
> > values converted to "bool", using true/false should be fine I think.
> 
> They're not necessarily needed but I think they improve the readability when they are used in the next three patches when defining the features of each Rx burst function. If you don't agree I can remove them.
> 

I'd tend to prefer assigning bools to just true/false for type-safety and
type-clarity. In terms of readability with defines like above: if we do
want separate defines for scattered, flex-desc etc. I'd tend toward having
them as enums and the variables below typed using those enums.
Unfortunately, that's not really feasible with the struct below, because
while bools only occupy 1 byte, even a two-element enum would use up 4
bytes per value, which is padding we cannot afford. :-(


> > 
> > > +struct ci_rx_path_features {
> > > +	uint32_t rx_offloads;
> > > +	enum rte_vect_max_simd simd_width;
> > > +	bool scattered;
> > > +	bool flex_desc;
> > > +	bool bulk_alloc;
> > > +	bool disabled;
> > > +};
> > > +
> > > +struct ci_rx_path_info {
> > > +	eth_rx_burst_t pkt_burst;
> > > +	const char *info;
> > > +	struct ci_rx_path_features features;
> > > +};
> > > +
> > >  static inline uint16_t
> > >  ci_rx_reassemble_packets(struct rte_mbuf **rx_bufs, uint16_t nb_bufs,
> > uint8_t *split_flags,
> > >  		struct rte_mbuf **pkt_first_seg, struct rte_mbuf
> > **pkt_last_seg,
> > > @@ -222,4 +243,86 @@ ci_rxq_vec_capable(uint16_t nb_desc, uint16_t
> > rx_free_thresh, uint64_t offloads)
> > >  	return true;
> > >  }
> > >
> > > +/**
> > > + * Select the best matching Rx path based on features
> > > + *
> > > + * @param req_features
> > > + *   The requested features for the Rx path
> > > + * @param infos
> > > + *   Array of information about the available Rx paths
> > > + * @param num_paths
> > > + *   Number of available paths in the infos array
> > > + * @param default_path
> > > + *   Index of the default path to use if no suitable path is found
> > > + *
> > > + * @return
> > > + *   The packet burst function index that best matches the requested
> > features,
> > > + *   or default_path if no suitable path is found
> > > + */
> > > +static inline int
> > > +ci_rx_path_select(struct ci_rx_path_features req_features,
> > > +			const struct ci_rx_path_info *infos,
> > > +			int num_paths,
> > > +			int default_path)
> > > +{
> > > +	int i, idx = -1;
> > > +	const struct ci_rx_path_features *current_features = NULL;
> > > +
> > > +	for (i = 0; i < num_paths; i++) {
> > > +		const struct ci_rx_path_features *path_features =
> > &infos[i].features;
> > > +
> > > +		/* Do not select a disabled rx path. */
> > > +		if (path_features->disabled)
> > > +			continue;
> > > +
> > > +		/* If requested, ensure the path uses the flexible descriptor. */
> > > +		if (path_features->flex_desc != req_features.flex_desc)
> > > +			continue;
> > > +
> > > +		/* If requested, ensure the path supports scattered RX. */
> > > +		if (path_features->scattered != req_features.scattered)
> > > +			continue;
> > > +
> > 
> > I think this test should be in a similar format for the next bulk-alloc
> > one. After all, if scattered Rx is requested, we must provide a scattered
> > path. However, if scattered is not requested, a scattered Rx path should
> > still work fine. So:
> > 
> > 	if (req_features.scattered && !path_features.scattered)
> > 		continue;
> 
> This would be a diversion from existing behaviour. Currently we never select a scattered function when it is not requested.
> Like you said it would still work, but the path selected may not be what users have come to expect.
> 

True. I suppose if we put this in place, we would also have to put in a
later check for whether the currently selected path is scattered and, if
scattered Rx is not requested, choose an otherwise equivalent
non-scattered path over it.

Given that we are looking for compatibility with what we have now, I'm ok
to keep things as they are.

/Bruce