> 04/07/2024 16:55, Stephen Hemminger: > > On Thu, 04 Jul 2024 16:14:42 +0200 > > Thomas Monjalon <tho...@monjalon.net> wrote: > > > > > > > Let’s ask Pavan why this flag is used in cn10k driver. > > > > > > > > > > From our perspective, WFE is available on all the supported arm > platforms in > > > > > DPDK. > > > > > Therefore, RTE_ARM_USE_WFE should be treated as a flag to choose > between > > > > > WFE > > > > > and non-WFE code paths due to performance reasons rather than as a > flag > > > > > that indicates > > > > > the availability of the instruction on the target CPU. > > > > > > > > > > > > > We are using this flag to allow application to choose between WFE and > non-WFE code path. > > > > The non-WFE path performs slightly better. > > > > > > What's the benefit of the WFE path then? > > > > WFE saves power at the expense of latency. > > Yes maybe there is a misunderstanding. > Pavan can you confirm you were saying "throughput is better on non-WFE"? > but "power consumption is lower on WFE path"? >
Yes, throughput is better on non-WFE and power consumption is lower on WFE path. But the statement cant be generalized for all use-cases, it depends on lot of factors. So, we use RTE_ARM_USE_WFE to allow applications to decide what they want. > > Maybe some form of hybrid approach would work best and could > > be always used. > > > > For example, many implementations of mutex do a short spin poll > > then fall back to a waiting primitive (like futex). This is already done across cnxk drivers and common layer I believe. >
