RE: [EXTERNAL] Re: [PATCH v2 2/2] eal: add Arm WFET in power management intrinsics

[Pavan Nikhilesh Bhagavatula <pbhagavatula@marvell.com>]

> 04/07/2024 16:55, Stephen Hemminger:
> > On Thu, 04 Jul 2024 16:14:42 +0200
> > Thomas Monjalon <thomas@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.

>