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

[Pavan Nikhilesh Bhagavatula]

> > 03/07/2024 15:27, Wathsala Wathawana Vithanage:
> > > > RTE_WAIT_UNTIL_EQUAL_ARCH_DEFINED #ifdef block.
> > > > > This patch fixes this issue by moving __RTE_ARM_WFE out of
> > > > > RTE_WAIT_UNTIL_EQUAL_ARCH_DEFINED block.
> > > > >
> > > > > Perhaps we should change RTE_ARM_USE_WFE to something like
> > > > > RTE_ARM_USE_WFE_IN_WAIT_UNTIL_EQUAL ?
> > > >
> > > > Yes perhaps.
> > > RTE_ARM_USE_WFE is already used in drivers/event/cnxk/cn10k_worker.h
> > > therefore RTE_ARM_USE_WFE_IN_WAIT_UNTIL_EQUAL is not suitable.
> > > I wouldn't mind keeping RTE_ARM_USE_WFE because "USE_WFE" sounds
> > like
> > > an instruction to use WFE rather than an indication of availability of the
> WFE
> > instruction.
> >
> > The problem is that the definition of this flag is not clear.
> > What is it doing?
> > If it's really disabling WFE, keep the #ifdef to not use it.
> >
> > For now, it is a nack of this patch for all reasons described before.
> >
> 
> Only other place where this flag is used is drivers/event/cnxk/cn10k_worker.h
> 
> b8dbcbe8a57 (Pavan Nikhilesh      2024-02-27 13:41:53 +0530 284) #if
> defined(RTE_ARM_USE_WFE)
> 
> 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.

> 
> 
>