> -----Original Message----- > From: [email protected] [mailto:lng-odp- > [email protected]] On Behalf Of ext Stuart Haslam > Sent: Thursday, July 31, 2014 12:47 AM > To: Maxim Uvarov > Cc: [email protected] > Subject: Re: [lng-odp] [PATCH] odp shm shared between processes > > On Tue, Jul 29, 2014 at 01:29:19PM +0100, Maxim Uvarov wrote: > > Add flag to odp_shm_reserve() to select if allocation memory is > > visible by thread or it's visible by other processes. > > > > Signed-off-by: Maxim Uvarov <[email protected]> > > --- > > Proposed API change allows to allocate memory chunks like > > buffer pools and queue specific things in memory visible > > by other processes. > > > > BR, > > Maxim. > > > > [..] > > > diff --git a/include/odp_shared_memory.h > b/include/odp_shared_memory.h > > index 8ac8847..10149ad 100644 > > --- a/include/odp_shared_memory.h > > +++ b/include/odp_shared_memory.h > > @@ -24,6 +24,13 @@ extern "C" { > > /** Maximum shared memory block name lenght in chars */ > > #define ODP_SHM_NAME_LEN 32 > > > > +typedef enum { > > + ODP_SHM_THREAD = 0, /**< Memory accessible by threads. */ > > + ODP_SHM_PROC, /**< Memory accessible by processes. > > + Will be created if not exist. */ > > + ODP_SHM_PROC_NOCREAT, /**< Memory accessible by processes. > > + Has to be created before usage.*/ > > +} odp_shm_e; > > > > It's not clear when you'd use ODP_SHM_PROC_NOCREAT. Is the expectation > that the first process uses ODP_SHM_PROC and subsequent processes use > ODP_SHM_PROC_NOCREAT, or is it OK to use ODP_SHM_PROC in all cases? (I > think it would be OK in this implementation, but is it defined > behaviour?) > > > /** > > * Reserve a block of shared memory > > @@ -31,10 +38,12 @@ extern "C" { > > * @param name Name of the block (maximum ODP_SHM_NAME_LEN - 1 > chars) > > * @param size Block size in bytes > > * @param align Block alignment in bytes > > + * @param flags Flags for shared memory creation, ODP_SHM_THREAD or > ODP_SHM_PROC > > Or ODP_SHM_PROC_NOCREAT?.. just remove the list from this comment, if > all values of odp_shm_e are valid then it's easy enough to look at the > enum itself. > > > * > > * @return Pointer to the reserved block, or NULL > > */ > > -void *odp_shm_reserve(const char *name, uint64_t size, uint64_t > align); > > +void *odp_shm_reserve(const char *name, uint64_t size, uint64_t > align, > > + odp_shm_e flags); > >
These changes are not needed for sharing memory within an ODP instance. An implementation should map shared memory correctly regardless of ODP application is running on threads/processes/bare metal. It's another thing to set up shared memory between two ODP instances (launched separately on the same or different VM), or between an ODP application and non-ODP application (or e.g. Linux kernel). Also there ODP application should not see the difference whether itself or the other party is composed from threads/processes/kernel driver/bare metal. Instead, I'd call this "shared memory for external communication", or even leave reservation of that memory to the application (it's system level problem to locate and set up that memory). Another way forward for IPC could be - not to create new ODP IPC, but add support for typical Linux mechanisms like IVSHMEM, KNI, VIRTIO. On ODP side those could managed like packet interfaces, and connected similarly to input/output queues. -Petri _______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
