[dpdk-dev] 回复: [RFC PATCH v3 4/5] lib/bpf: use wait event scheme for Rx/Tx iteration

[Feifei Wang]

> -----邮件原件-----
> 发件人: dev <dev-bounces at dpdk.org> 代表 Ananyev, Konstantin
> 发送时间: Friday, October 8, 2021 1:40 AM
> 收件人: Feifei Wang <Feifei.Wang2 at arm.com>
> 抄送: dev at dpdk.org; nd <nd at arm.com>; Ruifeng Wang
> <Ruifeng.Wang at arm.com>
> 主题: Re: [dpdk-dev] [RFC PATCH v3 4/5] lib/bpf: use wait event scheme for
> Rx/Tx iteration
> 
> 
> 
> > -----Original Message-----
> > From: Ananyev, Konstantin
> > Sent: Thursday, October 7, 2021 4:50 PM
> > To: Feifei Wang <feifei.wang2 at arm.com>
> > Cc: dev at dpdk.org; nd at arm.com; Ruifeng Wang <ruifeng.wang at arm.com>
> > Subject: RE: [RFC PATCH v3 4/5] lib/bpf: use wait event scheme for
> > Rx/Tx iteration
> >
> >
> >
> > >
> > > Signed-off-by: Feifei Wang <feifei.wang2 at arm.com>
> > > Reviewed-by: Ruifeng Wang <ruifeng.wang at arm.com>
> > > ---
> > >  lib/bpf/bpf_pkt.c | 9 +++------
> > >  1 file changed, 3 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/lib/bpf/bpf_pkt.c b/lib/bpf/bpf_pkt.c index
> > > 6e8248f0d6..3af15ae97b 100644
> > > --- a/lib/bpf/bpf_pkt.c
> > > +++ b/lib/bpf/bpf_pkt.c
> > > @@ -113,7 +113,7 @@ bpf_eth_cbi_unuse(struct bpf_eth_cbi *cbi)
> > > static void  bpf_eth_cbi_wait(const struct bpf_eth_cbi *cbi)  {
> > > -	uint32_t nuse, puse;
> > > +	uint32_t puse;
> > >
> > >  	/* make sure all previous loads and stores are completed */
> > >  	rte_smp_mb();
> > > @@ -122,11 +122,8 @@ bpf_eth_cbi_wait(const struct bpf_eth_cbi *cbi)
> > >
> > >  	/* in use, busy wait till current RX/TX iteration is finished */
> > >  	if ((puse & BPF_ETH_CBI_INUSE) != 0) {
> > > -		do {
> > > -			rte_pause();
> > > -			rte_compiler_barrier();
> > > -			nuse = cbi->use;
> > > -		} while (nuse == puse);
> > > +		rte_compiler_barrier();
> > > +		rte_wait_event_32(&cbi->use, UINT_MAX, puse, ==,
> > > +__ATOMIC_RELAXED);
> 
> Probably UINT32_MAX will be a bit better here.
That's right, UINT32_MAX is more suitable.
> 
> >
> > If we do use atomic load, while we still need a compiler_barrier() here?
Yes, compiler_barrier can be removed here since atomic_load can update the value in time.
> >
> > >  	}
> > >  }
> > >
> > > --
> > > 2.25.1