17/07/2020 18:43, Richardson, Bruce: > From: Thomas Monjalon <tho...@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" <m...@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.
