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

[Medvedkin, Vladimir]

Hi Alex,

On 05/07/2019 14:45, Alex Kiselev wrote:
> 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?
You right, x86 shouldn't be affected. If I understand asm correctly 
nexthop is written first for both _v20 and _v1604. Memory stores are 
retired in order.

-- 
Regards,
Vladimir