10/11/2017 04:30, Jia He:
> We watched a rte panic of mbuf_autotest in our qualcomm arm64 server
> (Amberwing).
>
> Root cause:
> In __rte_ring_move_cons_head()
> ...
> do {
> /* Restore n as it may change every loop */
> n = max;
>
> *old_head = r->cons.head; //1st load
> const uint32_t prod_tail = r->prod.tail; //2nd load
>
> In weak memory order architectures(powerpc,arm), the 2nd load might be
> reodered before the 1st load, that makes *entries is bigger than we wanted.
> This nasty reording messed enque/deque up.
>
> cpu1(producer) cpu2(consumer) cpu3(consumer)
> load r->prod.tail
> in enqueue:
> load r->cons.tail
> load r->prod.head
>
> store r->prod.tail
>
> load r->cons.head
> load r->prod.tail
> ...
> store r->cons.{head,tail}
> load r->cons.head
>
> Then, r->cons.head will be bigger than prod_tail, then make *entries very
> big and the consumer will go forward incorrectly.
>
> After this patch, the old cons.head will be recaculated after failure of
> rte_atomic32_cmpset
>
> There is no such issue on X86, because X86 is strong memory order model.
> But rte_smp_rmb() doesn't have impact on runtime performance on X86, so
> keep the same code without architectures specific concerns.
>
> Signed-off-by: Jia He <jia...@hxt-semitech.com>
> Signed-off-by: jie2....@hxt-semitech.com
> Signed-off-by: bing.z...@hxt-semitech.com
> Acked-by: Jerin Jacob <jerin.ja...@caviumnetworks.com>
> Acked-by: Jianbo Liu <jianbo....@arm.com>
> Cc: sta...@dpdk.org
Applied, thanks
