04/07/2024 12:55, 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.
What's the benefit of the WFE path then?
