We can discuss your proposal during the call, today. I have a question, though. If the ODP_SHM_NONCOHERENT flag is implemeneted, then I guess we are back to the need for a refresh() or similar function to update the cache. Or you could implement this flag in your implementation only, allocating shmem memory with this flag for packet and other object which you know when to "refresh" and leting a shm_reserve directely performed by the application reserve non-ODP_SHM_NONCOHERENT memory... I am not sure what is the proposal, but you are welcome to talk at the meeting. Regarding the ODP_SHM_PROC flag, I am non sure the code is correct: As I can see from the code, the mapping is anonymous when the flag is not present: This means the the function will behave differently depending on if ODP threads are implemented as linux threads or as linux processes (also depending on when the shm_reserve() is performed relative to the fork()). I assume this is not the real intention: My understanding at this stage is that shm_reserve() should always reserve shared memory visible from all ODP threads (non depending on their implementation as linux process vs linux thread). From the different discussion I have had, I believe the ODP_SHM_PROC flag is meant to enable this memory to also be sharable by non-ODP processes (normal non ODP linux processes).
Christophe. On 18 January 2016 at 20:59, Benoît Ganne <bga...@kalray.eu> wrote: > Hi all, > > Our problem is about shmem usage so far. After some discussions we believe > we have an acceptable solution: add a new flag to odp_shm_reserve(). So far > we have ODP_SHM_SW_ONLY and ODP_SHM_PROC, we would like to add something > like ODP_SHM_NONCOHERENT or similar. > It would allow to keep the default as it is today (and we will support it) > but would allow for optimizations where it is performance sensitive. > We can discuss the issue during the call and post a patch quickly if > everybody agree. > > By the way, what is the exact semantic of ODP_SHM_SW_ONLY and > ODP_SHM_PROC? From what I can see ODP_SHM_PROC relates to use MAP_ANONYMOUS > vs shm_open(), so mainly publishes the name of the mapping (so other > processes can use it) and I suspect that ODP_SHM_SW_ONLY relates to things > like DMA cache-coherency (well, lack of)? > > ben > > On 01/18/2016 10:38 AM, Christophe Milard wrote: > >> This seems to be a common opinion. I think it is nevertheless fair to >> give a chance to Nicolas to explain his case. >> >> On 18 January 2016 at 10:02, Ola Liljedahl <ola.liljed...@linaro.org >> <mailto:ola.liljed...@linaro.org>> wrote: >> >> On 15 January 2016 at 15:48, Christophe Milard >> <christophe.mil...@linaro.org <mailto:christophe.mil...@linaro.org>> >> wrote: >> >> On Tuesday's ARCH call, we will be discussing the above topic. >> Nicolas (Kalray) will try to join, but he is very uncertain at >> this stage (if he can be there)... >> >> Cache coherence is the norm today, non-coherent is an exception. >> My opinion: If possible and simple, make public interfaces not >> dependent on cache coherence. The reference implementation could >> depend on cache coherence. Anyone who wants to support non-coherent >> HW needs to provide the necessary support. >> >> >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org <mailto: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 >> >> > > -- > Benoît GANNE > Chief Architect, Kalray > +33 (0)648 125 843 >
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
