* [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).