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.
