Re: [dpdk-dev] [PATCH v6 0/8] fib: implement AVX512 vector lookup

[Thomas Monjalon <thomas@monjalon.net>]

17/07/2020 18:43, Richardson, Bruce:
> From: Thomas Monjalon <thomas@monjalon.net>
> > 15/07/2020 14:29, Medvedkin, Vladimir:
> > > On 15/07/2020 12:59, Thomas Monjalon wrote:
> > > > 15/07/2020 12:35, Medvedkin, Vladimir:
> > > >> On 15/07/2020 10:47, Thomas Monjalon wrote:
> > > >>> 14/07/2020 16:38, Stephen Hemminger:
> > > >>>> "Kinsella, Ray" <mdr@ashroe.eu> wrote:
> > > >>>>> On 13/07/2020 23:19, Stephen Hemminger wrote:
> > > >>>>>> Did anyone else see the recent AVX512 discussion from Linus:
> > > >>>>>>     "I hope AVX512 dies a painful death, and that Intel starts
> > fixing real problems
> > > >>>>>>      instead of trying to create magic instructions to then
> > create benchmarks that they can look good on.
> > > >>>>>
> > > >>>>> Yup - I saw this one.
> > > >>>>> Sweeping statements like these are good to provoke debate, the
> > truth is generally more nuanced.
> > > >>>>> If you continue to read the post, Linus appears to be mostly
> > questioning microprocessor design decisions.
> > > >>>>>
> > > >>>>> That is an interesting discussion, however the reality is that the
> > technology does exists and may be beneficial for Packet Processing.
> > > >>>>>
> > > >>>>> I would suggest, we continue to apply the same logic governing
> > adoption of any technology by DPDK.
> > > >>>>> When the technology is present and a clear benefit is shown, we
> > use it with caution.
> > > >>>>>
> > > >>>>> In the case of Vladimir's patch, the user has to explicitly
> > > >>>>> switch on the AVX512 lookup with RTE_FIB_DIR24_8_VECTOR_AVX512.
> > > >>>>
> > > >>>> Using what is available makes sense in DPDK.
> > > >>>
> > > >>> Why does it require explicit  enabling in application?
> > > >>> AVX512 is not reliable enough to be automatically used when
> > available?
> > > >>
> > > >> It is reliable enough. User have to explicitly trigger to avx512
> > > >> lookup because using avx512 instructions can reduce the frequency
> > > >> of your cores. The user knows their environment better. So the
> > > >> scalar version is used so as not to affect the frequency.
> > > >
> > > > So the user must know which micro-optimization is better for a code
> > > > they don't know. Reminder: an user is not a developper.
> > > > I understand we have no better solution though.
> > > > Can we improve the user experience with some recommendations, numbers,
> > etc?
> > > >
> > >
> > > In case where a user is a developer (dpdk users are mostly devs,
> > > aren't
> > > they?) who uses the fib library in their app may decide to switch to
> > > avx512 lookup using rte_fib_set_lookup_fn() when they know that their
> > > code is already using avx512 (ifdef, startup check, etc).
> > > In other case an app developer, for example, could provide to user
> > > command line option or some interactive command to switch lookup
> > function.
> > > I'd recommend to run testfib app with various "-v" options to evaluate
> > > lookup performance on a target system to make a decision.
> > 
> > I think this is the difference between a library for hackers, and a
> > product for end-users.
> > We are not building a product, but we can make a step in that direction by
> > documenting some knowledge.
> > I don't know exactly what it means in this case, so I'll let others
> > suggest some doc improvements (if anyone cares).
> > 
> 
> We have got a patchset in the works to try and make AVX-512 use simpler for 20.11,
> by providing both developer APIs and end-user cmdline flags to control this
> centrally for DPDK, rather than having each library provide its own magic hooks
> to optionally enable this support. As part of that set, we'll see about what
> doc updates need to be made also - again covering both developer and end-app user.
> 
> Hopefully we can get that set out soon to get early feedback and reach a good
> conclusion.

We cannot merge anymore in 20.08 because we passed -rc1.
I am in favor of merging this feature the day after 20.08 release.