On 21 April 2015 at 15:08, Ola Liljedahl <[email protected]> wrote:
> On 21 April 2015 at 14:01, Nicolas Morey-Chaisemartin <[email protected]> > wrote: > >> >> On 04/21/2015 01:31 PM, Ola Liljedahl wrote: >> >> On 17 April 2015 at 10:46, Nicolas Morey-Chaisemartin < >> <[email protected]>[email protected]> 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? >> >> >> Yes sorry. I was looking at the ODP-DPDK sources too and got mixed up. >> >> >> >>> 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). >> >> >> OK >> >> >> >>> 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? >> >> >> I am not sure where the odp_atomic_internal should be moved (I'm still >> learning where things are supposed to be and why), but with some >> guidelines, I'd be happy to propose a patch for this. >> > If the public odp/atomic.h references functions defined in > odp_atomic_internal.h, then that header file must also be included in the > files that are installed by "make install". > I do not see that odp/atomic.h references to odp_atomic_internal.h functions. I just see that in odp/atomic.h memory model is binded to relaxed while in odp_atomic_internal.h you can select it. Best way to check that is run ./scripts/builddeb. It builds debian package. And while building it compiles libodp installs it then compiles tests and references to installed library. Because test/performance/odp_atomic.c was compiled then it's clear that reference to odp_atomic_internal.h is not needed. > I don't know if this influences the location of odp_atomic_internal.h in > the ODP source structure. Maybe the makefiles can grab files (to be > installed) from anywhere. Maxim, Anders? > > _internal.h prefixes says that file has internal content for platform only and it should not be installed. Do you want make in ODP API change memory model for atomics? In that case you need to move _internal.h to atomic.h with proper renaming. And _internal.h is not needed in that case. Best regards, Maxim. > >> >> Thanks for the info >> >> Nicolas >> >> >
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
