On 17 April 2015 at 10:46, Nicolas Morey-Chaisemartin <nmo...@kalray.eu> wrote:
> Hello every one, > > I am currently working on porting the linux-generic implementation of DPDK > on Kalray architecture and slightly pulling my hair out with all the > atomics. > Surely you mean ODP and not DPDK? > By going through the code I noticed that there are a *lot* of functions > for atomics that do almost the same thing but not exactly. > The differences are quite important here... The public odp/atomic.h uses a relaxed memory model so only suitable for things like statistics and shared sequence numbers etc. The internal atomics support supports a memory ordering parameter which make these functions usable for designing lock-less multithreaded data structures (and the implementation of the locks themselves). As it is not supposed that the user will design their own lock-less data structures, this API is internal to linux-generic (and thus may not exist on all platforms). > Fox example in include/odp/atomic.h, all the load/store/add/sub function > are defined using GCC builtins, but almost the same functions (adding the > memory model as a parameters) are also defined in odp_atomic_internal.h > Wouldn't it make sense to reuse these internals functions in atomic.h so > there is only one place where we rely on "external" atomic features? > Yes I agree. The internal functions have their names prepended with an "_" so it should be obvious to the user that those are not part of the public API. odp_atomic_inteŕnal.h must then become part of the ODP release (for linux-generic). Patch? > > The reason behind this is that our GCC does not support all the atomic > builtins yet and I'd rather factor some code than reimplement the same > atomic functions all over the place :) > > Also, odp_atomic_internal.h defined the _odp_atomic_flag_t and the > associated lock/release helpers. > But the type is not used for odp_spin_lock, and neither the type nor the > helpers are used for odp_atomic_u64_t when GCC does not support 64b atomic > operations. > Is there a reason for that? > Probably because odp_atomic_flag was introduced after odp_spin_lock was implemented. One could use odp_atomic_flag in the vanilla spin lock implementation. I am not that happy with the emulated odp_atomic_u64 implementation. Using a lock per atomic variable increases the size of the variable which may cause consequences down the line. An alternative would be to use a separate fixed-size array of (spin) locks and map each odp_atomic_u64 variable to one of the locks using e.g. a simple hash function. The question is which architectures in practice will need the emulated support (PPC32 is one), most of the networking world is already 64-bit (and 32-bit ARMv7 supports 64-bit atomic operations). > Regards > > > -- > Nicolas Morey Chaisemartin > Phone : +33 6 42 46 68 87 > > _______________________________________________ > lng-odp mailing list > lng-odp@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/lng-odp >
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
