[dpdk-dev] [PATCH v2 01/17] eal: add max SIMD bitwidth

[Bruce Richardson]

On Fri, Sep 18, 2020 at 02:13:02AM +0000, Honnappa Nagarahalli wrote:
> <snip>
> 
> > >
> > >>>
> > >>  > diff --git a/lib/librte_eal/include/rte_eal.h
> > >> b/lib/librte_eal/include/rte_eal.h
> > >>>> index ddcf6a2e7a..8148f650f2 100644
> > >>>> --- a/lib/librte_eal/include/rte_eal.h
> > >>>> +++ b/lib/librte_eal/include/rte_eal.h
> > >>>> @@ -43,6 +43,13 @@ enum rte_proc_type_t {
> > >>>>  	RTE_PROC_INVALID
> > >>>>  };
> > >>>>
> > >>>> +enum rte_max_simd_t {
> > >>> We could add a RTE_MAX_SIMD = 0. Arm platforms can use this to
> > >>> choose
> > >> SVE.
> > >>>
> > >>
> > >> Is zero the best value for this? Would setting it to MAX_INT or some
> > >> other big number be better, in terms of comparisons operations, or
> > >> does that just not apply at all with SVE?
> > > I suggested zero as the bitwidth can be specified from the command line. It
> > would be much easier to input zero vs other number.
> > 
> > Right, but it doesn't end up being that intuitive as interface
> > 0 is enabled, 64 is not, 128 is enabled etc ....
> > 
> > Suggest we use a max 16bit integer as 0xFFFF?
> I think there are 2 things here:
> 1) What is the internal representation (for ex: the value of the enum)? Here assigning 0xFFFF should be fine.
> 2) The input value at the command line. Is it possible to say that, if the user does not provide anything, then we set the option as 0xFFFF? This would mean that SVE would be used by default on Arm platforms (which is ok for me).
>

Make sense. That all is perfectly doable because the initial default value
is set per architecture.