[dpdk-dev] [PATCH] net/bnxt: allow configuring vector mode

[dpdk-dev] [PATCH] net/bnxt: allow configuring vector mode

[Stephen Hemminger]

The bnxt driver has vector mode but it has limitations.
For example, rte_flow mark won't work in vector mode.
For this reason the user should be able to disable vector mode
as part of the config.

Make the configuration use the same as other drivers with
vector mode: ixge, i40e, ...

This will also make future support of vector mode on other
architectures possible.

Fixes: bc4a000f2f53 ("net/bnxt: implement SSE vector mode")
Cc: lance.richardson@broadcom.com
Cc: stable@dpdk.org
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 config/common_base             |  1 +
 drivers/net/bnxt/Makefile      |  2 +-
 drivers/net/bnxt/bnxt_ethdev.c | 10 +++-------
 drivers/net/bnxt/bnxt_ring.c   |  4 ++--
 drivers/net/bnxt/bnxt_rxr.c    |  3 +++
 5 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/config/common_base b/config/common_base
index 7ca2f28b19c8..3c719c7cbfc3 100644
--- a/config/common_base
+++ b/config/common_base
@@ -219,6 +219,7 @@ CONFIG_RTE_LIBRTE_BNX2X_DEBUG_PERIODIC=n
 # Compile burst-oriented Broadcom BNXT PMD driver
 #
 CONFIG_RTE_LIBRTE_BNXT_PMD=y
+CONFIG_RTE_LIBRTE_BNXT_INC_VECTOR=y
 
 #
 # Compile burst-oriented Chelsio Terminator (CXGBE) PMD
diff --git a/drivers/net/bnxt/Makefile b/drivers/net/bnxt/Makefile
index b77532b8179b..85d6df6b5aa0 100644
--- a/drivers/net/bnxt/Makefile
+++ b/drivers/net/bnxt/Makefile
@@ -40,7 +40,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_BNXT_PMD) += bnxt_irq.c
 SRCS-$(CONFIG_RTE_LIBRTE_BNXT_PMD) += bnxt_util.c
 SRCS-$(CONFIG_RTE_LIBRTE_BNXT_PMD) += rte_pmd_bnxt.c
 ifeq ($(CONFIG_RTE_ARCH_X86), y)
-SRCS-$(CONFIG_RTE_LIBRTE_BNXT_PMD) += bnxt_rxtx_vec_sse.c
+SRCS-$(CONFIG_RTE_LIBRTE_BNXT_INC_VECTOR) += bnxt_rxtx_vec_sse.c
 endif
 
 #
diff --git a/drivers/net/bnxt/bnxt_ethdev.c b/drivers/net/bnxt/bnxt_ethdev.c
index 18aa313fd8c1..701de33784b2 100644
--- a/drivers/net/bnxt/bnxt_ethdev.c
+++ b/drivers/net/bnxt/bnxt_ethdev.c
@@ -757,8 +757,7 @@ bnxt_receive_function(struct rte_eth_dev *eth_dev)
 {
 	struct bnxt *bp = eth_dev->data->dev_private;
 
-#ifdef RTE_ARCH_X86
-#ifndef RTE_LIBRTE_IEEE1588
+#ifdef RTE_BNXT_INC_VECTOR
 	/*
 	 * Vector mode receive can be enabled only if scatter rx is not
 	 * in use and rx offloads are limited to VLAN stripping and
@@ -787,7 +786,6 @@ bnxt_receive_function(struct rte_eth_dev *eth_dev)
 		    eth_dev->data->port_id,
 		    eth_dev->data->scattered_rx,
 		    eth_dev->data->dev_conf.rxmode.offloads);
-#endif
 #endif
 	bp->flags &= ~BNXT_FLAG_RX_VECTOR_PKT_MODE;
 	return bnxt_recv_pkts;
@@ -796,8 +794,7 @@ bnxt_receive_function(struct rte_eth_dev *eth_dev)
 static eth_tx_burst_t
 bnxt_transmit_function(__rte_unused struct rte_eth_dev *eth_dev)
 {
-#ifdef RTE_ARCH_X86
-#ifndef RTE_LIBRTE_IEEE1588
+#ifdef RTE_BNXT_INC_VECTOR
 	/*
 	 * Vector mode transmit can be enabled only if not using scatter rx
 	 * or tx offloads.
@@ -815,7 +812,6 @@ bnxt_transmit_function(__rte_unused struct rte_eth_dev *eth_dev)
 		    eth_dev->data->port_id,
 		    eth_dev->data->scattered_rx,
 		    eth_dev->data->dev_conf.txmode.offloads);
-#endif
 #endif
 	return bnxt_xmit_pkts;
 }
@@ -2234,7 +2230,7 @@ int bnxt_mtu_set_op(struct rte_eth_dev *eth_dev, uint16_t new_mtu)
 	new_pkt_size = new_mtu + RTE_ETHER_HDR_LEN + RTE_ETHER_CRC_LEN +
 		       VLAN_TAG_SIZE * BNXT_NUM_VLANS;
 
-#ifdef RTE_ARCH_X86
+#ifdef RTE_BNXT_INC_VECTOR
 	/*
 	 * If vector-mode tx/rx is active, disallow any MTU change that would
 	 * require scattered receive support.
diff --git a/drivers/net/bnxt/bnxt_ring.c b/drivers/net/bnxt/bnxt_ring.c
index d6e4e8a28138..9a4a0f21418d 100644
--- a/drivers/net/bnxt/bnxt_ring.c
+++ b/drivers/net/bnxt/bnxt_ring.c
@@ -608,7 +608,7 @@ int bnxt_alloc_hwrm_rx_ring(struct bnxt *bp, int queue_index)
 		bnxt_db_write(&rxr->ag_db, rxr->ag_prod);
 	}
 	rxq->index = queue_index;
-#ifdef RTE_ARCH_X86
+#ifdef RTE_BNXT_INC_VECTOR
 	bnxt_rxq_vec_setup(rxq);
 #endif
 
@@ -713,7 +713,7 @@ int bnxt_alloc_hwrm_rings(struct bnxt *bp)
 		bnxt_db_write(&rxr->rx_db, rxr->rx_prod);
 		bnxt_db_write(&rxr->ag_db, rxr->ag_prod);
 		rxq->index = i;
-#ifdef RTE_ARCH_X86
+#ifdef RTE_BNXT_INC_VECTOR
 		bnxt_rxq_vec_setup(rxq);
 #endif
 	}
diff --git a/drivers/net/bnxt/bnxt_rxr.c b/drivers/net/bnxt/bnxt_rxr.c
index bef9720f590c..f9087bea89b9 100644
--- a/drivers/net/bnxt/bnxt_rxr.c
+++ b/drivers/net/bnxt/bnxt_rxr.c
@@ -18,6 +18,9 @@
 #include "hsi_struct_def_dpdk.h"
 #ifdef RTE_LIBRTE_IEEE1588
 #include "bnxt_hwrm.h"
+#ifdef RTE_BNXT_INC_VECTOR
+#error "bnxt: IEEE1588 is incompatiable with vector mode"
+#endif
 #endif
 
 /*
-- 
2.20.1

Re: [dpdk-dev] [PATCH] net/bnxt: allow configuring vector mode

[Lance Richardson]

Hi Stephen,

On Thu, Mar 5, 2020 at 1:45 AM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
<snip>
>
> Make the configuration use the same as other drivers with
> vector mode: ixge, i40e, ...
s/ixge/ixgbe/?

>
<snip>
> This will also make future support of vector mode on other
> architectures possible.
>
> Fixes: bc4a000f2f53 ("net/bnxt: implement SSE vector mode")
<snip>
> +#error "bnxt: IEEE1588 is incompatiable with vector mode"
> +#endif
s/incompatiable/incompatible/


This was this approach taken in the initial patch set to add bnxt
vector mode support,
however based on feedback the current approach was used instead. That discussion
can be found here:
      http://patches.dpdk.org/patch/53683/

If mark support could be treated as a receive offload, it would be
possible to choose
the non-vector receive handler based on whether mark is enabled. Adding a kvargs
option to disable vector mode might be another possibility. Otherwise,
a build-time
configuration option does seem to be useful.

LGTM... with the above:

Acked-by: Lance Richardson <lance.richardson@broadcom.com>

Regards,
    Lance

Re: [dpdk-dev] [PATCH] net/bnxt: allow configuring vector mode

[Stephen Hemminger]

On Thu, 5 Mar 2020 15:10:48 -0500
Lance Richardson <lance.richardson@broadcom.com> wrote:

> Hi Stephen,
> 
> On Thu, Mar 5, 2020 at 1:45 AM Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> >  
> <snip>
> >
> > Make the configuration use the same as other drivers with
> > vector mode: ixge, i40e, ...  
> s/ixge/ixgbe/?
> 
> >  
> <snip>
> > This will also make future support of vector mode on other
> > architectures possible.
> >
> > Fixes: bc4a000f2f53 ("net/bnxt: implement SSE vector mode")  
> <snip>
> > +#error "bnxt: IEEE1588 is incompatiable with vector mode"
> > +#endif  
> s/incompatiable/incompatible/
> 
> 
> This was this approach taken in the initial patch set to add bnxt
> vector mode support,
> however based on feedback the current approach was used instead. That discussion
> can be found here:
>       http://patches.dpdk.org/patch/53683/
> 
> If mark support could be treated as a receive offload, it would be
> possible to choose
> the non-vector receive handler based on whether mark is enabled. Adding a kvargs
> option to disable vector mode might be another possibility. Otherwise,
> a build-time
> configuration option does seem to be useful.
> 
> LGTM... with the above:
> 
> Acked-by: Lance Richardson <lance.richardson@broadcom.com>

What ever solution must be consistent across all drivers.

Re: [dpdk-dev] [dpdk-stable] [PATCH] net/bnxt: allow configuring vector mode

[Ferruh Yigit]

On 3/5/2020 10:18 PM, Stephen Hemminger wrote:
> On Thu, 5 Mar 2020 15:10:48 -0500
> Lance Richardson <lance.richardson@broadcom.com> wrote:
> 
>> Hi Stephen,
>>
>> On Thu, Mar 5, 2020 at 1:45 AM Stephen Hemminger
>> <stephen@networkplumber.org> wrote:
>>>  
>> <snip>
>>>
>>> Make the configuration use the same as other drivers with
>>> vector mode: ixge, i40e, ...  
>> s/ixge/ixgbe/?
>>
>>>  
>> <snip>
>>> This will also make future support of vector mode on other
>>> architectures possible.
>>>
>>> Fixes: bc4a000f2f53 ("net/bnxt: implement SSE vector mode")  
>> <snip>
>>> +#error "bnxt: IEEE1588 is incompatiable with vector mode"
>>> +#endif  
>> s/incompatiable/incompatible/
>>
>>
>> This was this approach taken in the initial patch set to add bnxt
>> vector mode support,
>> however based on feedback the current approach was used instead. That discussion
>> can be found here:
>>       http://patches.dpdk.org/patch/53683/
>>
>> If mark support could be treated as a receive offload, it would be
>> possible to choose
>> the non-vector receive handler based on whether mark is enabled. Adding a kvargs
>> option to disable vector mode might be another possibility. Otherwise,
>> a build-time
>> configuration option does seem to be useful.
>>
>> LGTM... with the above:
>>
>> Acked-by: Lance Richardson <lance.richardson@broadcom.com>
> 
> What ever solution must be consistent across all drivers.
> 

I saw Ajit merged this patch to brcm tree, but I am not sure about it. We have
already removed this compile time option from some PMDs, and driver tries to
detect to use or not to use vectorization transparently.

This config is also a problem for the meson, which always sets the flag in a
hardcoded way.

But also I am not sure about to need to enable/disable vectorization explicitly,
this patch seems because of this need. As far as I remember in the past this
type of runtime configuration rejected to not make driver configuration more
complex.

Re: [dpdk-dev] [dpdk-stable] [PATCH] net/bnxt: allow configuring vector mode

[Ajit Khaparde]

On Tue, Mar 31, 2020 at 4:36 AM Ferruh Yigit <ferruh.yigit@intel.com> wrote:

> On 3/5/2020 10:18 PM, Stephen Hemminger wrote:
> > On Thu, 5 Mar 2020 15:10:48 -0500
> > Lance Richardson <lance.richardson@broadcom.com> wrote:
> >
> >> Hi Stephen,
> >>
> >> On Thu, Mar 5, 2020 at 1:45 AM Stephen Hemminger
> >> <stephen@networkplumber.org> wrote:
> >>>
> >> <snip>
> >>>
> >>> Make the configuration use the same as other drivers with
> >>> vector mode: ixge, i40e, ...
> >> s/ixge/ixgbe/?
> >>
> >>>
> >> <snip>
> >>> This will also make future support of vector mode on other
> >>> architectures possible.
> >>>
> >>> Fixes: bc4a000f2f53 ("net/bnxt: implement SSE vector mode")
> >> <snip>
> >>> +#error "bnxt: IEEE1588 is incompatiable with vector mode"
> >>> +#endif
> >> s/incompatiable/incompatible/
> >>
> >>
> >> This was this approach taken in the initial patch set to add bnxt
> >> vector mode support,
> >> however based on feedback the current approach was used instead. That
> discussion
> >> can be found here:
> >>       http://patches.dpdk.org/patch/53683/
> >>
> >> If mark support could be treated as a receive offload, it would be
> >> possible to choose
> >> the non-vector receive handler based on whether mark is enabled. Adding
> a kvargs
> >> option to disable vector mode might be another possibility. Otherwise,
> >> a build-time
> >> configuration option does seem to be useful.
> >>
> >> LGTM... with the above:
> >>
> >> Acked-by: Lance Richardson <lance.richardson@broadcom.com>
> >
> > What ever solution must be consistent across all drivers.
> >
>
> I saw Ajit merged this patch to brcm tree, but I am not sure about it. We
> have
> already removed this compile time option from some PMDs, and driver tries
> to
> detect to use or not to use vectorization transparently.
>
> This config is also a problem for the meson, which always sets the flag in
> a
> hardcoded way.
>
> But also I am not sure about to need to enable/disable vectorization
> explicitly,
> this patch seems because of this need. As far as I remember in the past
> this
> type of runtime configuration rejected to not make driver configuration
> more
> complex.

Since we need a way to disable or enable vector mode.
May be a dev parameter could be used?
That way it would not interfere with the meson builds and also allow a
user/application to set vector mode setting as desired.

Re: [dpdk-dev] [dpdk-stable] [PATCH] net/bnxt: allow configuring vector mode

[Thomas Monjalon]

31/03/2020 16:31, Ajit Khaparde:
> On Tue, Mar 31, 2020 at 4:36 AM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> 
> > On 3/5/2020 10:18 PM, Stephen Hemminger wrote:
> > > On Thu, 5 Mar 2020 15:10:48 -0500
> > > Lance Richardson <lance.richardson@broadcom.com> wrote:
> > >
> > >> Hi Stephen,
> > >>
> > >> On Thu, Mar 5, 2020 at 1:45 AM Stephen Hemminger
> > >> <stephen@networkplumber.org> wrote:
> > >>>
> > >> <snip>
> > >>>
> > >>> Make the configuration use the same as other drivers with
> > >>> vector mode: ixge, i40e, ...
> > >> s/ixge/ixgbe/?
> > >>
> > >>>
> > >> <snip>
> > >>> This will also make future support of vector mode on other
> > >>> architectures possible.
> > >>>
> > >>> Fixes: bc4a000f2f53 ("net/bnxt: implement SSE vector mode")
> > >> <snip>
> > >>> +#error "bnxt: IEEE1588 is incompatiable with vector mode"
> > >>> +#endif
> > >> s/incompatiable/incompatible/
> > >>
> > >>
> > >> This was this approach taken in the initial patch set to add bnxt
> > >> vector mode support,
> > >> however based on feedback the current approach was used instead. That
> > discussion
> > >> can be found here:
> > >>       http://patches.dpdk.org/patch/53683/
> > >>
> > >> If mark support could be treated as a receive offload, it would be
> > >> possible to choose
> > >> the non-vector receive handler based on whether mark is enabled. Adding
> > a kvargs
> > >> option to disable vector mode might be another possibility. Otherwise,
> > >> a build-time
> > >> configuration option does seem to be useful.
> > >>
> > >> LGTM... with the above:
> > >>
> > >> Acked-by: Lance Richardson <lance.richardson@broadcom.com>
> > >
> > > What ever solution must be consistent across all drivers.
> > >
> >
> > I saw Ajit merged this patch to brcm tree, but I am not sure about it. We
> > have
> > already removed this compile time option from some PMDs, and driver tries
> > to
> > detect to use or not to use vectorization transparently.
> >
> > This config is also a problem for the meson, which always sets the flag in
> > a
> > hardcoded way.
> >
> > But also I am not sure about to need to enable/disable vectorization
> > explicitly,
> > this patch seems because of this need. As far as I remember in the past
> > this
> > type of runtime configuration rejected to not make driver configuration
> > more
> > complex.
> 
> Since we need a way to disable or enable vector mode.

Why do you need to disable vector optimization?
Is it for debugging?

> May be a dev parameter could be used?
> That way it would not interfere with the meson builds and also allow a
> user/application to set vector mode setting as desired.

Yes diasbling optimization could be done in devargs.

Re: [dpdk-dev] [dpdk-stable] [PATCH] net/bnxt: allow configuring vector mode

[Stephen Hemminger]

On Tue, 31 Mar 2020 17:43:55 +0200
Thomas Monjalon <thomas@monjalon.net> wrote:

> 31/03/2020 16:31, Ajit Khaparde:
> > On Tue, Mar 31, 2020 at 4:36 AM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> >   
> > > On 3/5/2020 10:18 PM, Stephen Hemminger wrote:  
> > > > On Thu, 5 Mar 2020 15:10:48 -0500
> > > > Lance Richardson <lance.richardson@broadcom.com> wrote:
> > > >  
> > > >> Hi Stephen,
> > > >>
> > > >> On Thu, Mar 5, 2020 at 1:45 AM Stephen Hemminger
> > > >> <stephen@networkplumber.org> wrote:  
> > > >>>  
> > > >> <snip>  
> > > >>>
> > > >>> Make the configuration use the same as other drivers with
> > > >>> vector mode: ixge, i40e, ...  
> > > >> s/ixge/ixgbe/?
> > > >>  
> > > >>>  
> > > >> <snip>  
> > > >>> This will also make future support of vector mode on other
> > > >>> architectures possible.
> > > >>>
> > > >>> Fixes: bc4a000f2f53 ("net/bnxt: implement SSE vector mode")  
> > > >> <snip>  
> > > >>> +#error "bnxt: IEEE1588 is incompatiable with vector mode"
> > > >>> +#endif  
> > > >> s/incompatiable/incompatible/
> > > >>
> > > >>
> > > >> This was this approach taken in the initial patch set to add bnxt
> > > >> vector mode support,
> > > >> however based on feedback the current approach was used instead. That  
> > > discussion  
> > > >> can be found here:
> > > >>       http://patches.dpdk.org/patch/53683/
> > > >>
> > > >> If mark support could be treated as a receive offload, it would be
> > > >> possible to choose
> > > >> the non-vector receive handler based on whether mark is enabled. Adding  
> > > a kvargs  
> > > >> option to disable vector mode might be another possibility. Otherwise,
> > > >> a build-time
> > > >> configuration option does seem to be useful.
> > > >>
> > > >> LGTM... with the above:
> > > >>
> > > >> Acked-by: Lance Richardson <lance.richardson@broadcom.com>  
> > > >
> > > > What ever solution must be consistent across all drivers.
> > > >  
> > >
> > > I saw Ajit merged this patch to brcm tree, but I am not sure about it. We
> > > have
> > > already removed this compile time option from some PMDs, and driver tries
> > > to
> > > detect to use or not to use vectorization transparently.
> > >
> > > This config is also a problem for the meson, which always sets the flag in
> > > a
> > > hardcoded way.
> > >
> > > But also I am not sure about to need to enable/disable vectorization
> > > explicitly,
> > > this patch seems because of this need. As far as I remember in the past
> > > this
> > > type of runtime configuration rejected to not make driver configuration
> > > more
> > > complex.  
> > 
> > Since we need a way to disable or enable vector mode.  
> 
> Why do you need to disable vector optimization?
> Is it for debugging?

The rte_flow mark operation does not work with the vector optimization.

The choice to use vector mode is done by the driver earlier in
the initialization process, and then when application programs rte_flow
it has a problem; the flow create would fail.

Re: [dpdk-dev] [dpdk-stable] [PATCH] net/bnxt: allow configuring vector mode

[Thomas Monjalon]

31/03/2020 17:58, Stephen Hemminger:
> On Tue, 31 Mar 2020 17:43:55 +0200
> Thomas Monjalon <thomas@monjalon.net> wrote:
> > 31/03/2020 16:31, Ajit Khaparde:
> > > On Tue, Mar 31, 2020 at 4:36 AM Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> > > > I saw Ajit merged this patch to brcm tree, but I am not sure about it. We
> > > > have
> > > > already removed this compile time option from some PMDs, and driver tries
> > > > to
> > > > detect to use or not to use vectorization transparently.
> > > >
> > > > This config is also a problem for the meson, which always sets the flag in
> > > > a
> > > > hardcoded way.
> > > >
> > > > But also I am not sure about to need to enable/disable vectorization
> > > > explicitly,
> > > > this patch seems because of this need. As far as I remember in the past
> > > > this
> > > > type of runtime configuration rejected to not make driver configuration
> > > > more
> > > > complex.  
> > > 
> > > Since we need a way to disable or enable vector mode.  
> > 
> > Why do you need to disable vector optimization?
> > Is it for debugging?
> 
> The rte_flow mark operation does not work with the vector optimization.
> 
> The choice to use vector mode is done by the driver earlier in
> the initialization process, and then when application programs rte_flow
> it has a problem; the flow create would fail.

Could we imagine switching the Rx implementation dynamically between 2 bursts?

Re: [dpdk-dev] [PATCH] net/bnxt: allow configuring vector mode

[Ajit Khaparde]

On Wed, Mar 4, 2020 at 10:45 PM Stephen Hemminger <
stephen@networkplumber.org> wrote:

> The bnxt driver has vector mode but it has limitations.
> For example, rte_flow mark won't work in vector mode.
> For this reason the user should be able to disable vector mode
> as part of the config.
>
> Make the configuration use the same as other drivers with
> vector mode: ixge, i40e, ...
>
> This will also make future support of vector mode on other
> architectures possible.
>
> Fixes: bc4a000f2f53 ("net/bnxt: implement SSE vector mode")
> Cc: lance.richardson@broadcom.com
> Cc: stable@dpdk.org
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
>
Patch applied to dpdk-next-net-brcm. Thanks



> ---
>  config/common_base             |  1 +
>  drivers/net/bnxt/Makefile      |  2 +-
>  drivers/net/bnxt/bnxt_ethdev.c | 10 +++-------
>  drivers/net/bnxt/bnxt_ring.c   |  4 ++--
>  drivers/net/bnxt/bnxt_rxr.c    |  3 +++
>  5 files changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/config/common_base b/config/common_base
> index 7ca2f28b19c8..3c719c7cbfc3 100644
> --- a/config/common_base
> +++ b/config/common_base
> @@ -219,6 +219,7 @@ CONFIG_RTE_LIBRTE_BNX2X_DEBUG_PERIODIC=n
>  # Compile burst-oriented Broadcom BNXT PMD driver
>  #
>  CONFIG_RTE_LIBRTE_BNXT_PMD=y
> +CONFIG_RTE_LIBRTE_BNXT_INC_VECTOR=y
>
>  #
>  # Compile burst-oriented Chelsio Terminator (CXGBE) PMD
> diff --git a/drivers/net/bnxt/Makefile b/drivers/net/bnxt/Makefile
> index b77532b8179b..85d6df6b5aa0 100644
> --- a/drivers/net/bnxt/Makefile
> +++ b/drivers/net/bnxt/Makefile
> @@ -40,7 +40,7 @@ SRCS-$(CONFIG_RTE_LIBRTE_BNXT_PMD) += bnxt_irq.c
>  SRCS-$(CONFIG_RTE_LIBRTE_BNXT_PMD) += bnxt_util.c
>  SRCS-$(CONFIG_RTE_LIBRTE_BNXT_PMD) += rte_pmd_bnxt.c
>  ifeq ($(CONFIG_RTE_ARCH_X86), y)
> -SRCS-$(CONFIG_RTE_LIBRTE_BNXT_PMD) += bnxt_rxtx_vec_sse.c
> +SRCS-$(CONFIG_RTE_LIBRTE_BNXT_INC_VECTOR) += bnxt_rxtx_vec_sse.c
>  endif
>
>  #
> diff --git a/drivers/net/bnxt/bnxt_ethdev.c
> b/drivers/net/bnxt/bnxt_ethdev.c
> index 18aa313fd8c1..701de33784b2 100644
> --- a/drivers/net/bnxt/bnxt_ethdev.c
> +++ b/drivers/net/bnxt/bnxt_ethdev.c
> @@ -757,8 +757,7 @@ bnxt_receive_function(struct rte_eth_dev *eth_dev)
>  {
>         struct bnxt *bp = eth_dev->data->dev_private;
>
> -#ifdef RTE_ARCH_X86
> -#ifndef RTE_LIBRTE_IEEE1588
> +#ifdef RTE_BNXT_INC_VECTOR
>         /*
>          * Vector mode receive can be enabled only if scatter rx is not
>          * in use and rx offloads are limited to VLAN stripping and
> @@ -787,7 +786,6 @@ bnxt_receive_function(struct rte_eth_dev *eth_dev)
>                     eth_dev->data->port_id,
>                     eth_dev->data->scattered_rx,
>                     eth_dev->data->dev_conf.rxmode.offloads);
> -#endif
>  #endif
>         bp->flags &= ~BNXT_FLAG_RX_VECTOR_PKT_MODE;
>         return bnxt_recv_pkts;
> @@ -796,8 +794,7 @@ bnxt_receive_function(struct rte_eth_dev *eth_dev)
>  static eth_tx_burst_t
>  bnxt_transmit_function(__rte_unused struct rte_eth_dev *eth_dev)
>  {
> -#ifdef RTE_ARCH_X86
> -#ifndef RTE_LIBRTE_IEEE1588
> +#ifdef RTE_BNXT_INC_VECTOR
>         /*
>          * Vector mode transmit can be enabled only if not using scatter rx
>          * or tx offloads.
> @@ -815,7 +812,6 @@ bnxt_transmit_function(__rte_unused struct rte_eth_dev
> *eth_dev)
>                     eth_dev->data->port_id,
>                     eth_dev->data->scattered_rx,
>                     eth_dev->data->dev_conf.txmode.offloads);
> -#endif
>  #endif
>         return bnxt_xmit_pkts;
>  }
> @@ -2234,7 +2230,7 @@ int bnxt_mtu_set_op(struct rte_eth_dev *eth_dev,
> uint16_t new_mtu)
>         new_pkt_size = new_mtu + RTE_ETHER_HDR_LEN + RTE_ETHER_CRC_LEN +
>                        VLAN_TAG_SIZE * BNXT_NUM_VLANS;
>
> -#ifdef RTE_ARCH_X86
> +#ifdef RTE_BNXT_INC_VECTOR
>         /*
>          * If vector-mode tx/rx is active, disallow any MTU change that
> would
>          * require scattered receive support.
> diff --git a/drivers/net/bnxt/bnxt_ring.c b/drivers/net/bnxt/bnxt_ring.c
> index d6e4e8a28138..9a4a0f21418d 100644
> --- a/drivers/net/bnxt/bnxt_ring.c
> +++ b/drivers/net/bnxt/bnxt_ring.c
> @@ -608,7 +608,7 @@ int bnxt_alloc_hwrm_rx_ring(struct bnxt *bp, int
> queue_index)
>                 bnxt_db_write(&rxr->ag_db, rxr->ag_prod);
>         }
>         rxq->index = queue_index;
> -#ifdef RTE_ARCH_X86
> +#ifdef RTE_BNXT_INC_VECTOR
>         bnxt_rxq_vec_setup(rxq);
>  #endif
>
> @@ -713,7 +713,7 @@ int bnxt_alloc_hwrm_rings(struct bnxt *bp)
>                 bnxt_db_write(&rxr->rx_db, rxr->rx_prod);
>                 bnxt_db_write(&rxr->ag_db, rxr->ag_prod);
>                 rxq->index = i;
> -#ifdef RTE_ARCH_X86
> +#ifdef RTE_BNXT_INC_VECTOR
>                 bnxt_rxq_vec_setup(rxq);
>  #endif
>         }
> diff --git a/drivers/net/bnxt/bnxt_rxr.c b/drivers/net/bnxt/bnxt_rxr.c
> index bef9720f590c..f9087bea89b9 100644
> --- a/drivers/net/bnxt/bnxt_rxr.c
> +++ b/drivers/net/bnxt/bnxt_rxr.c
> @@ -18,6 +18,9 @@
>  #include "hsi_struct_def_dpdk.h"
>  #ifdef RTE_LIBRTE_IEEE1588
>  #include "bnxt_hwrm.h"
> +#ifdef RTE_BNXT_INC_VECTOR
> +#error "bnxt: IEEE1588 is incompatiable with vector mode"
> +#endif
>  #endif
>
>  /*
> --
> 2.20.1
>
>

[dpdk-dev] [PATCH] net/bnxt: disable vector mode if flow mark is used

[Stephen Hemminger]

Since vector mode can't be used with flow mark actions.
The choice of vector or non-vector mode is done dynamically
earlier in the initialization process (config) and the user
application has no direct control over the selection.

Therefore the best resolution to the conflict is for
the driver to disable vector mode if it needs to.

Fixes: 94eb699bc82e ("net/bnxt: support flow mark action")
Cc: ajit.khaparde@broadcom.com
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
 drivers/net/bnxt/bnxt_flow.c | 13 +++++--------
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/net/bnxt/bnxt_flow.c b/drivers/net/bnxt/bnxt_flow.c
index 44734272fbea..7715a7b45173 100644
--- a/drivers/net/bnxt/bnxt_flow.c
+++ b/drivers/net/bnxt/bnxt_flow.c
@@ -18,6 +18,7 @@
 #include "bnxt_hwrm.h"
 #include "bnxt_ring.h"
 #include "bnxt_rxq.h"
+#include "bnxt_rxr.h"
 #include "bnxt_vnic.h"
 #include "hsi_struct_def_dpdk.h"
 
@@ -1405,14 +1406,10 @@ bnxt_validate_and_parse_flow(struct rte_eth_dev *dev,
 	case RTE_FLOW_ACTION_TYPE_MARK:
 		if (bp->flags & BNXT_FLAG_RX_VECTOR_PKT_MODE) {
 			PMD_DRV_LOG(DEBUG,
-				    "Disable vector processing for mark\n");
-			rte_flow_error_set(error,
-					   ENOTSUP,
-					   RTE_FLOW_ERROR_TYPE_ACTION,
-					   act,
-					   "Disable vector processing for mark");
-			rc = -rte_errno;
-			goto ret;
+				    "Disabling vector processing for mark\n");
+
+			bp->flags &= ~BNXT_FLAG_RX_VECTOR_PKT_MODE;
+			dev->rx_pkt_burst = &bnxt_recv_pkts;
 		}
 
 		if (bp->mark_table == NULL) {
-- 
2.20.1