[dpdk-dev] [PATCH v2 03/17] doc: add detail on using max SIMD bitwidth

[Bruce Richardson]

On Sun, Sep 06, 2020 at 10:20:30PM +0000, Ananyev, Konstantin wrote:
> > This patch adds documentation on the usage of the max SIMD bitwidth EAL
> > setting, and how to use it to enable AVX-512 at runtime.
> > 
> > Cc: Anatoly Burakov <anatoly.burakov at intel.com>
> > Cc: John McNamara <john.mcnamara at intel.com>
> > Cc: Marko Kovacevic <marko.kovacevic at intel.com>
> > 
> > Signed-off-by: Ciara Power <ciara.power at intel.com>
> > ---
> >  doc/guides/howto/avx512.rst                   | 36 +++++++++++++++++++
> >  doc/guides/linux_gsg/eal_args.include.rst     | 12 +++++++
> >  .../prog_guide/env_abstraction_layer.rst      | 31 ++++++++++++++++
> >  3 files changed, 79 insertions(+)
> >  create mode 100644 doc/guides/howto/avx512.rst
> > 
> > diff --git a/doc/guides/howto/avx512.rst b/doc/guides/howto/avx512.rst
> > new file mode 100644
> > index 0000000000..ebae0f2b4f
> > --- /dev/null
> > +++ b/doc/guides/howto/avx512.rst
> > @@ -0,0 +1,36 @@
> > +..  SPDX-License-Identifier: BSD-3-Clause
> > +    Copyright(c) 2020 Intel Corporation.
> > +
> > +
> > +Using AVX-512 with DPDK
> > +=======================
> > +
> > +AVX-512 is not used by default in DPDK, but it can be selected at runtime by apps through the use of EAL API,
> > +and by the user with a commandline argument. DPDK has a setting for max SIMD bitwidth,
> > +which can be modified and will then limit the vector path taken by the code.
> 
> It's is a good idea to have such ability,
> though just one global variable for all DPDK lib/drivers
> seems a bit coarse to me.
> Let say we have 2 libs: libA and libB.
> Both do have RTE_MAX_512_SIMD specific code-path,
> though libA  would cause frequency level change, while libB wouldn't.
> So user (to avoid frequency level change) would have to block
> 512_SIMD for both libs.
> I think it would be much better to follow the strategy we use for log-level:
> there is a global simd_width, but each DDPK entity (lib/driver) also has   
> it's own simd_width that overrules a global one (more fine-grained control).

That for me is a nightmare scenario. How is the user meant to know what
libs could cause him a frequency or not, or is he meant to determine that
empirically by trial and error on each platform? This scenario is
completely unlike logging in that it's non-obvious to the user, and so
needs to be kept as consumable as possible to the app-developer and the
user. Unless we find a concrete scenario where having a single switch is
causing real user problems, I'd much rather keep things simple. See also
answer below, where I point out that the main target of this is developers,
who can use this flag to indicate what vector bitwidth their app uses, and
then allow DPDK to match that.

> 
> > +
> > +
> > +Using the API in apps
> > +---------------------
> > +
> > +Apps can request DPDK uses AVX-512 at runtime, if it provides improved application performance.
> > +This can be done by modifying the EAL setting for max SIMD bitwidth to 512, as by default it is 256,
> > +which does not allow for AVX-512.
> > +
> > +.. code-block:: c
> > +
> > +   rte_set_max_simd_bitwidth(RTE_MAX_512_SIMD);
> > +
> > +This API should only be called once at initialization, before EAL init.
> 
> If the only possible usage scenario for that function is init time before  EAL init,
> then do we really need it at all?
> As we have cmd-line flag anyway?
> User can achieve similar goal, by just:  rte_eal_init(,..."--force-max-simd-bitwidth=..."...); 

Ideally, the user should never know or care about the cmdline flag, it's
only for testing. The main criteria for allowing DPDK to use longer
instruction sets is whether the application itself will similarly use them,
and that's something for the programmer to do. Having the programmer muck
about with cmdline arguments is less than ideal, so a proper API is
warrented here. The reason for the note about EAL init, is that we don't
want libraries to have to check the max bitwidth each time an API is
called, so we want to have a way to prevent people changing things at
runtime. This therefore seemed simplest.

/Bruce