* [PATCH 0/1] net/i40e: unset vector flag when scalar path is chosen @ 2025-12-17 14:54 Ciara Loftus 2025-12-17 14:54 ` [PATCH 1/1] " Ciara Loftus 0 siblings, 1 reply; 5+ messages in thread From: Ciara Loftus @ 2025-12-17 14:54 UTC (permalink / raw) To: dev; +Cc: Ciara Loftus The tx_vec_allowed flag should be set to false if a scalar Tx path is chosen. If possible this commit can be squashed into the commit it fixes on the next-net-intel tree. If the SSE removal series [1] is merged before this patch is applied, this patch does not require any changes. [1] https://patches.dpdk.org/project/dpdk/cover/20251217143223.3208830-1-ciara.loftus@intel.com/ Ciara Loftus (1): net/i40e: unset vector flag when scalar path is chosen drivers/net/intel/i40e/i40e_rxtx.c | 3 +++ 1 file changed, 3 insertions(+) -- 2.43.0 ^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH 1/1] net/i40e: unset vector flag when scalar path is chosen 2025-12-17 14:54 [PATCH 0/1] net/i40e: unset vector flag when scalar path is chosen Ciara Loftus @ 2025-12-17 14:54 ` Ciara Loftus 2025-12-17 15:08 ` Bruce Richardson 0 siblings, 1 reply; 5+ messages in thread From: Ciara Loftus @ 2025-12-17 14:54 UTC (permalink / raw) To: dev; +Cc: Ciara Loftus The tx_vec_allowed flag should be set to false if a scalar Tx path is chosen. Fixes: 1ff08bb7ad90 ("net/i40e: use common Tx path selection infrastructure") Signed-off-by: Ciara Loftus <ciara.loftus@intel.com> --- drivers/net/intel/i40e/i40e_rxtx.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/intel/i40e/i40e_rxtx.c b/drivers/net/intel/i40e/i40e_rxtx.c index 2db58c6b24..dd859bda4e 100644 --- a/drivers/net/intel/i40e/i40e_rxtx.c +++ b/drivers/net/intel/i40e/i40e_rxtx.c @@ -3631,6 +3631,9 @@ i40e_set_tx_function(struct rte_eth_dev *dev) ad->tx_func_type == I40E_TX_ALTIVEC || ad->tx_func_type == I40E_TX_AVX2) dev->recycle_tx_mbufs_reuse = i40e_recycle_tx_mbufs_reuse_vec; + + if (i40e_tx_path_infos[ad->tx_func_type].features.simd_width < RTE_VECT_SIMD_128) + ad->tx_vec_allowed = false; } int -- 2.43.0 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 1/1] net/i40e: unset vector flag when scalar path is chosen 2025-12-17 14:54 ` [PATCH 1/1] " Ciara Loftus @ 2025-12-17 15:08 ` Bruce Richardson 2025-12-17 15:18 ` Loftus, Ciara 0 siblings, 1 reply; 5+ messages in thread From: Bruce Richardson @ 2025-12-17 15:08 UTC (permalink / raw) To: Ciara Loftus; +Cc: dev On Wed, Dec 17, 2025 at 02:54:36PM +0000, Ciara Loftus wrote: > The tx_vec_allowed flag should be set to false if a scalar Tx path is > chosen. > > Fixes: 1ff08bb7ad90 ("net/i40e: use common Tx path selection infrastructure") > > Signed-off-by: Ciara Loftus <ciara.loftus@intel.com> > --- > drivers/net/intel/i40e/i40e_rxtx.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/net/intel/i40e/i40e_rxtx.c b/drivers/net/intel/i40e/i40e_rxtx.c > index 2db58c6b24..dd859bda4e 100644 > --- a/drivers/net/intel/i40e/i40e_rxtx.c > +++ b/drivers/net/intel/i40e/i40e_rxtx.c > @@ -3631,6 +3631,9 @@ i40e_set_tx_function(struct rte_eth_dev *dev) > ad->tx_func_type == I40E_TX_ALTIVEC || > ad->tx_func_type == I40E_TX_AVX2) > dev->recycle_tx_mbufs_reuse = i40e_recycle_tx_mbufs_reuse_vec; > + > + if (i40e_tx_path_infos[ad->tx_func_type].features.simd_width < RTE_VECT_SIMD_128) > + ad->tx_vec_allowed = false; > } > Under what circumstances would this be a problem, or under what circumstances would we have this situaion? /Bruce ^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: [PATCH 1/1] net/i40e: unset vector flag when scalar path is chosen 2025-12-17 15:08 ` Bruce Richardson @ 2025-12-17 15:18 ` Loftus, Ciara 2025-12-17 15:33 ` Bruce Richardson 0 siblings, 1 reply; 5+ messages in thread From: Loftus, Ciara @ 2025-12-17 15:18 UTC (permalink / raw) To: Richardson, Bruce; +Cc: dev > Subject: Re: [PATCH 1/1] net/i40e: unset vector flag when scalar path is > chosen > > On Wed, Dec 17, 2025 at 02:54:36PM +0000, Ciara Loftus wrote: > > The tx_vec_allowed flag should be set to false if a scalar Tx path is > > chosen. > > > > Fixes: 1ff08bb7ad90 ("net/i40e: use common Tx path selection > infrastructure") > > > > Signed-off-by: Ciara Loftus <ciara.loftus@intel.com> > > --- > > drivers/net/intel/i40e/i40e_rxtx.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/net/intel/i40e/i40e_rxtx.c > b/drivers/net/intel/i40e/i40e_rxtx.c > > index 2db58c6b24..dd859bda4e 100644 > > --- a/drivers/net/intel/i40e/i40e_rxtx.c > > +++ b/drivers/net/intel/i40e/i40e_rxtx.c > > @@ -3631,6 +3631,9 @@ i40e_set_tx_function(struct rte_eth_dev *dev) > > ad->tx_func_type == I40E_TX_ALTIVEC || > > ad->tx_func_type == I40E_TX_AVX2) > > dev->recycle_tx_mbufs_reuse = > i40e_recycle_tx_mbufs_reuse_vec; > > + > > + if (i40e_tx_path_infos[ad->tx_func_type].features.simd_width < > RTE_VECT_SIMD_128) > > + ad->tx_vec_allowed = false; > > } > > > Under what circumstances would this be a problem, or under what > circumstances would we have this situaion? The circumstances we would have this situation is when the driver determines that tx vectorisation is allowed but we end up selecting a scalar path. The result would be "vector_tx" being set for the txq during tx_queue_start and later during tx_queue_stop, the wrong path being taken in ci_txq_release_all_mbufs > > /Bruce ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH 1/1] net/i40e: unset vector flag when scalar path is chosen 2025-12-17 15:18 ` Loftus, Ciara @ 2025-12-17 15:33 ` Bruce Richardson 0 siblings, 0 replies; 5+ messages in thread From: Bruce Richardson @ 2025-12-17 15:33 UTC (permalink / raw) To: Loftus, Ciara; +Cc: dev On Wed, Dec 17, 2025 at 03:18:42PM +0000, Loftus, Ciara wrote: > > Subject: Re: [PATCH 1/1] net/i40e: unset vector flag when scalar path is > > chosen > > > > On Wed, Dec 17, 2025 at 02:54:36PM +0000, Ciara Loftus wrote: > > > The tx_vec_allowed flag should be set to false if a scalar Tx path is > > > chosen. > > > > > > Fixes: 1ff08bb7ad90 ("net/i40e: use common Tx path selection > > infrastructure") > > > > > > Signed-off-by: Ciara Loftus <ciara.loftus@intel.com> > > > --- > > > drivers/net/intel/i40e/i40e_rxtx.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/drivers/net/intel/i40e/i40e_rxtx.c > > b/drivers/net/intel/i40e/i40e_rxtx.c > > > index 2db58c6b24..dd859bda4e 100644 > > > --- a/drivers/net/intel/i40e/i40e_rxtx.c > > > +++ b/drivers/net/intel/i40e/i40e_rxtx.c > > > @@ -3631,6 +3631,9 @@ i40e_set_tx_function(struct rte_eth_dev *dev) > > > ad->tx_func_type == I40E_TX_ALTIVEC || > > > ad->tx_func_type == I40E_TX_AVX2) > > > dev->recycle_tx_mbufs_reuse = > > i40e_recycle_tx_mbufs_reuse_vec; > > > + > > > + if (i40e_tx_path_infos[ad->tx_func_type].features.simd_width < > > RTE_VECT_SIMD_128) > > > + ad->tx_vec_allowed = false; > > > } > > > > > Under what circumstances would this be a problem, or under what > > circumstances would we have this situaion? > > The circumstances we would have this situation is when the driver > determines that tx vectorisation is allowed but we end up selecting > a scalar path. The result would be "vector_tx" being set for the txq > during tx_queue_start and later during tx_queue_stop, the wrong > path being taken in ci_txq_release_all_mbufs > Would this be better fixed by some refactoring to chose the release function based on ad->tx_func_type, rather than having a separate vector flag? If not, may I suggest that you remove the if condition, and just do: ad->tx_vec_allowed = (i40e_tx_path_infos[ad->tx_func_type].features.simd_width < RTE_VECT_SIMD_128); ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-12-17 15:33 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2025-12-17 14:54 [PATCH 0/1] net/i40e: unset vector flag when scalar path is chosen Ciara Loftus 2025-12-17 14:54 ` [PATCH 1/1] " Ciara Loftus 2025-12-17 15:08 ` Bruce Richardson 2025-12-17 15:18 ` Loftus, Ciara 2025-12-17 15:33 ` Bruce Richardson
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).