> 08/03/2019 16:50, Ananyev, Konstantin: > > 08/03/2019 16:05, Gavin Hu (Arm Technology China): > > > Anyway, on x86, smp_rmb, as a compiler barrier, applies to load/store, not > only load/load. > > > > Yes, that's true, but I think that's happened by coincidence, not > > intentionally. > > > > > This is the case also for arm, arm64, ppc32, ppc64. > > > I will submit a patch to expand the definition of this API. > > > > I understand your intention, but that does mean we would also need to > > change not only rte_smp_rmb() but rte_rmb() too (to keep things consistent)? > > That sounds worring. > > Might be better to keep smp_rmb() definition as it is, and introduce > > new function that fits your purposes (smp_rwmb or smp_load_store_barrier)? Looking at rte_rmb, rte_io_rmb, rte_cio_rmb implementations for Arm, they all provide load/store barrier as well. If other architectures also provide load/store barrier with rte_xxx_rmb, then we could extend the meaning of the existing APIs.
Even if a new API is provided, we need to do provide the same APIs for IO and CIO variants. > > How is it managed in other projects? In my experience, I usually have been changing the algorithms to use C11 memory model. So, I have not come across this issue yet. Others can comment. >
