On Tue, 31 Mar 2020 17:43:55 +0200
Thomas Monjalon <tho...@monjalon.net> wrote:
> 31/03/2020 16:31, Ajit Khaparde:
> > On Tue, Mar 31, 2020 at 4:36 AM Ferruh Yigit <ferruh.yi...@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.richard...@broadcom.com> wrote:
> > > >
> > > >> Hi Stephen,
> > > >>
> > > >> On Thu, Mar 5, 2020 at 1:45 AM Stephen Hemminger
> > > >> <step...@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.richard...@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.
