Re: [PATCH v5 11/24] drivers: replace rte_atomic16 with stdatomic

[Stephen Hemminger <stephen@networkplumber.org>]

 > >         dpbp_node->dpbp_id = dpbp_id;
> > -       rte_atomic16_init(&dpbp_node->in_use);
> > +       dpbp_node->in_use = 0;
>
> The previous code implies an ordering barrier, so it guarantees that
> dpbp_node->dpbp_id is visible before in_use, while the new code
> doesn't. isn't the a problem?

No barrier is lost, because there was never one there.

rte_atomic16_init() was a plain non-atomic store:

    static inline void
    rte_atomic16_init(rte_atomic16_t *v)
    {
            v->cnt = 0;
    }

That is the generic definition in lib/eal/include/generic/rte_atomic.h,
and no architecture overrides it -- x86, ppc, arm and the rest only
override rte_atomic16_test_and_set(), never _init() or _clear(). So the
old code ordered nothing with respect to the dpbp_id store either.

> aren't rte_atomic_flag_test_and_set_explicit/rte_atomic_flag_clear_explicit
> a better candidates instead of
> rte_atomic_compare_exchange_strong_explicit/rte_atomic_store_explicit ?

There are currently no users of rte_atomic_flag_* anywhere in the tree, and that is not an accident.
atomic_flag exists mainly so C11 could guarantee that at least one atomic type is always lock-free
on all architectures.  But for DPDK it is a bad fit.
On every architecture DPDK targets, plain integer atomics are
already lock-free, so the guarantee buys nothing, and the missing
operations are a real cost -- you cannot even read the flag without
modifying it. It is a standards compromise that saw very little use
anywhere, in DPDK or outside it.

I would recommend deprecating and removing those macros as well.