> > 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.
