[dpdk-dev] [PATCH v3 1/3] rwlock: reimplement with atomic builtins

Gavin Hu (Arm Technology China) Gavin.Hu at arm.com
Tue Mar 19 09:31:05 CET 2019


Hi Konstantin, 

> -----Original Message-----
> From: Ananyev, Konstantin <konstantin.ananyev at intel.com>
> Sent: Friday, March 15, 2019 7:41 PM
> To: Joyce Kong (Arm Technology China) <Joyce.Kong at arm.com>;
> dev at dpdk.org
> Cc: nd <nd at arm.com>; Gavin Hu (Arm Technology China)
> <Gavin.Hu at arm.com>; jerinj at marvell.com; chaozhu at linux.vnet.ibm.com;
> Richardson, Bruce <bruce.richardson at intel.com>; thomas at monjalon.net;
> hemant.agrawal at nxp.com; Honnappa Nagarahalli
> <Honnappa.Nagarahalli at arm.com>
> Subject: RE: [PATCH v3 1/3] rwlock: reimplement with atomic builtins
> 
> Hi,
> 
> 
> > The __sync builtin based implementation generates full memory
> > barriers ('dmb ish') on Arm platforms. Using C11 atomic builtins
> > to generate one way barriers.
> >
> > Here is the assembly code of __sync_compare_and_swap builtin.
> > __sync_bool_compare_and_swap(dst, exp, src);
> >    0x000000000090f1b0 <+16>:    e0 07 40 f9 ldr x0, [sp, #8]
> >    0x000000000090f1b4 <+20>:    e1 0f 40 79 ldrh    w1, [sp, #6]
> >    0x000000000090f1b8 <+24>:    e2 0b 40 79 ldrh    w2, [sp, #4]
> >    0x000000000090f1bc <+28>:    21 3c 00 12 and w1, w1, #0xffff
> >    0x000000000090f1c0 <+32>:    03 7c 5f 48 ldxrh   w3, [x0]
> >    0x000000000090f1c4 <+36>:    7f 00 01 6b cmp w3, w1
> >    0x000000000090f1c8 <+40>:    61 00 00 54 b.ne    0x90f1d4
> > <rte_atomic16_cmpset+52>  // b.any
> >    0x000000000090f1cc <+44>:    02 fc 04 48 stlxrh  w4, w2, [x0]
> >    0x000000000090f1d0 <+48>:    84 ff ff 35 cbnz    w4, 0x90f1c0
> > <rte_atomic16_cmpset+32>
> >    0x000000000090f1d4 <+52>:    bf 3b 03 d5 dmb ish
> >    0x000000000090f1d8 <+56>:    e0 17 9f 1a cset    w0, eq  // eq = none
> >
> > Signed-off-by: Gavin Hu <gavin.hu at arm.com>
> > Tested-by: Joyce Kong <joyce.kong at arm.com>
> > Acked-by: Jerin Jacob <jerinj at marvell.com>
> > ---
> 
> Wouldn't it be plausible to change _try_ functions to use __atomic too (for
> consistency)?
> Apart from that looks good to me.
> Konstantin

Sure, we will do it in next version. 



More information about the dev mailing list