Re: [RFC PATCH 10/14] net/intel: introduce infrastructure for Rx path selection

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

On Wed, Aug 06, 2025 at 11:14:58AM +0100, Loftus, Ciara wrote:
> > 
> > On Fri, Jul 25, 2025 at 12:49:15PM +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
> > >
> > > Signed-off-by: Ciara Loftus <ciara.loftus@intel.com>
> > > ---
> > 
> > This is a good idea to simplify things. Some comments inline below.
> > 
> > /Bruce
> > 
> > >  drivers/net/intel/common/rx.h | 110
> > ++++++++++++++++++++++++++++++++++
> > >  1 file changed, 110 insertions(+)
> > >
> > > diff --git a/drivers/net/intel/common/rx.h b/drivers/net/intel/common/rx.h
> > > index 70b597e8dc..6e9d81fecf 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"
> > >
> > > @@ -20,6 +21,12 @@
> > >  #define CI_VPMD_DESCS_PER_LOOP_WIDE 8
> > >  #define CI_VPMD_RX_REARM_THRESH     64
> > >
> > > +#define CI_RX_BURST_NO_FEATURES		0
> > > +#define CI_RX_BURST_FEATURE_SCATTERED	RTE_BIT32(0)
> > > +#define CI_RX_BURST_FEATURE_FLEX	RTE_BIT32(1)
> > > +#define CI_RX_BURST_FEATURE_BULK_ALLOC	RTE_BIT32(2)
> > > +#define CI_RX_BURST_FEATURE_IS_DISABLED	RTE_BIT32(3)
> > > +
> > >  struct ci_rx_queue;
> > >
> > >  struct ci_rx_entry {
> > > @@ -125,6 +132,19 @@ struct ci_rx_queue {
> > >  	};
> > >  };
> > >
> > > +
> > > +struct ci_rx_burst_features {
> > > +	uint32_t rx_offloads;
> > > +	enum rte_vect_max_simd simd_width;
> > > +	uint32_t other_features_mask;
> > 
> > Rather than using a bitmask here and having to do bit ops, how about just
> > using individual boolean variables for each setting. Given that we only
> > have 4 settings right now (disabled, scattered, flex, and bulk-alloc), the
> > actual struct size here will be the same, but the code will be simpler.
> > Since this is not a datapath function, I'm not worried if the overall
> > struct size grows a bit over time.
> > 
> > I'd also note that in the structure below, we need an extra 4-bytes of
> > padding anyway, since the pointers require it to be 8-byte aligned, so we
> > can have up to 8 flags in the rx_burst_features struct without affecting
> > the size of the burst_info struct.
> 
> Thanks for the feedback on the series. No objections with the feedback on the other patches.
> 
> The choice to use a bitmask here wasn't for space-saving rather for readability in later patches when we define the ci_rx_burst_features for each path in each driver.
> For example, if a path just has the scattered feature, it's features can be defined like:
> {PATH_OFFLOADS, PATH_SIMD_WIDTH, CI_RX_BURST_FEATURE_SCATTERED}
> instead of the below if we were to split the mask into booleans:
> {PATH_OFFLOADS, PATH_SIMD_WIDTH, CI_RX_BURST_FEATURE_SCATTERED, 0, 0, 0}
> 
> Maybe it's not that much of an improvement in readability. And I suppose it introduces a little bit of extra complexity in the select() function when reading the values of the mask instead of reading simple booleans. So I'm happy to go the boolean route if you feel it's better.
> 

Hmm, good point. I suppose it doesn't matter much either way. In terms of
readability, if we do use bool values, we can omit any trailing zero values
at the end to shorten things. Alternatively, if using bool values, we may
switch to defining the structs using the ".name = value" syntax, again
omitting not-set values. [If you want, you can even make the boolean values
a separate struct, which means you can mix the two as:
{PATH_OFFLOADS, PATH_SIMD_WIDTH, { .scattered = true, .flex= true }}
though that may look a bit strange]

As I say, it doesn't really matter either way, so perhaps try implementing
with bool values and see what it looks like - then just decide which you
prefer. I'm happy to go along with whatever you decide works best here.

/Bruce