[dpdk-dev] [PATCH v3 3/3] lib/lpm: memory orderings to avoid race conditions for v20

[Alex Kiselev]

Hi,

> <snip>
>
> >
> > As a general remark consider writing all of the tbl entries including
> > tbl8 with atomic_store. Now "lpm->tbl8[j] = new_tbl8_entry;" is looks like
> >
> >       1e9:       44 88 9c 47 40 01 00    mov
> > %r11b,0x2000140(%rdi,%rax,2) <-write first byte
> >       1f0:       02
> >       1f1:       48 83 c0 01             add    $0x1,%rax
> >       1f5:       42 88 8c 47 41 01 00    mov %cl,0x2000141(%rdi,%r8,2) <-write
> > second byte
> >       1fc:       02
> >
> > This may cause an incorrect nexthop to be returned. If the byte with valid flag
> > is updated first, the old(and maybe invalid) next hop could be returned.
> +1
>
> It is surprising that the compiler is not generating a single 32b store. As you mentioned 'relaxed' __atomic_store_n should be good.

Am I right that x86 platform is not affected by the bug since
store-store could not be reordered on x86?

-- 
Alex