On Thu, Dec 11, 2025 at 11:56:12AM +0000, Bruce Richardson wrote: > On Tue, Dec 09, 2025 at 11:26:42AM +0000, Ciara Loftus wrote: > > Replace the existing complicated logic with the use of the common > > function. Introduce a new feature "simple tx" to the common > > infrastructure which represents whether or not a simplified transmit > > path may be selected for the device. > > > > Signed-off-by: Ciara Loftus <[email protected]> > > --- > > drivers/net/intel/common/tx.h | 10 ++ > > drivers/net/intel/ice/ice_rxtx.c | 142 +++++++++----------- > > drivers/net/intel/ice/ice_rxtx.h | 30 ++++- > > drivers/net/intel/ice/ice_rxtx_vec_common.h | 35 +---- > > drivers/net/intel/ice/ice_rxtx_vec_sse.c | 6 - > > 5 files changed, 103 insertions(+), 120 deletions(-) > > > > diff --git a/drivers/net/intel/common/tx.h b/drivers/net/intel/common/tx.h > > index c6c1904ba3..3480c5e07c 100644 > > --- a/drivers/net/intel/common/tx.h > > +++ b/drivers/net/intel/common/tx.h > > @@ -118,15 +118,21 @@ struct ci_tx_queue { > > }; > > }; > > > > +struct ci_tx_path_features_extra { > > + bool simple_tx; > > +}; > > + > > struct ci_tx_path_features { > > uint32_t tx_offloads; > > enum rte_vect_max_simd simd_width; > > + struct ci_tx_path_features_extra extra; > > Two thoughts on this - do we really need a substructure here rather than > just adding the flags directly to the path_features structure? Secondly, > should this addition not be included in patch 1, which adds the rest of the > support for the tx path selection logic? I don't see a reason to put half > the infrastructure there and the rest here. > Just as follow-up here. I see there are more extra features added in later drivers, but those (AFAIK) are pretty much limited to the drivers adding them. Multiple drivers have simple scalar paths so I think this could be part of the base infrastructure in patch one, while the others can stay with their individual drivers.
/Bruce
