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).
