Re: [dpdk-dev] Use WFE for spinlock and ring

[Bruce Richardson <bruce.richardson@intel.com>]

On Thu, Apr 29, 2021 at 05:20:05PM +0200, Thomas Monjalon wrote:
> 29/04/2021 16:28, Ruifeng Wang:
> > From: Thomas Monjalon <thomas@monjalon.net>
> > > 28/04/2021 11:30, Ruifeng Wang:
> > > > From: David Marchand <david.marchand@redhat.com>
> > > > > On Sun, Apr 25, 2021 at 7:57 AM Ruifeng Wang <ruifeng.wang@arm.com>
> > > > > wrote:
> > > > > >
> > > > > > The rte_wait_until_equal_xxx APIs abstract the functionality of
> > > > > > 'polling for a memory location to become equal to a given value'[1].
> > > > > >
> > > > > > Use the API for the rte spinlock and ring implementations.
> > > > > > With the wait until equal APIs being stable, changes will not impact ABI.
> > > > >
> > > > > Afaics, there is no ARM target with WFE enabled and we lost ability
> > > > > to enable WFE support with removal of the make build system.
> > > >
> > > > WFE can be enabled with direct meson file change.
> > > > WFE is not intended to be enabled by default. It can be enabled based
> > > > on benchmarking result on hardware.
> > > > >
> > > > > $ git grep RTE_ARM_USE_WFE
> > > > > config/arm/meson.build:        ['RTE_ARM_USE_WFE', false],
> > > > > lib/eal/arm/include/rte_pause_64.h:#ifdef RTE_ARM_USE_WFE
> > > > >
> > > > > How did you enable WFE to test this series?
> > > >
> > > > I modified meson file to test.
> > > > Tests were also done with WFE disabled to make sure no degradation with
> > > generic implementation.
> > > 
> > > I don't understand the usage.
> > > Which platform should use it?
> > 
> > Platforms that implement WFE semantic (e.g. N1) can use.
> > The user can enable this feature for power efficiency purpose. But there is something to
> > note as described in commit message 1be7855d77 when the API was introduced. 
> > 
> > > Should it be a compile-time option?
> > 
> > Yes, it should be a compile-time option.
> > It can be configured via c_args meson option?
> 
> +Cc Bruce for discussing how to enable such feature.
> 
> The problem with c_args is that the application has no way to know.
> 
Agree about c_args not being a great choice. Why does this need to be a
compile-time option? Can runtime support not be detected in some manner?