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? > 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.