[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 at 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 at broadcom.com> wrote:
> > >
> > >> Hi Stephen,
> > >>
> > >> On Thu, Mar 5, 2020 at 1:45 AM Stephen Hemminger
> > >> <stephen at 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 at 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.