When I think about IPC, it is message passing between different programs (different processes, different address spaces, possibly even different machines). IPC provides services like address resolution (some form of name lookup), being able to respond to messages, a model for message typing (so you can parse and understand messages from different senders). One of the main use cases for IPC would be between the control plane (which does not use ODP) and the data plane (which would be implemented using ODP).
Synchronization between threads using the same address space can be done in many way (e.g. by posting ODP buffers to queues). What kind of generic helpers are needed here? -- Ola On 13 March 2015 at 09:49, Maxim Uvarov <[email protected]> wrote: > What was decision of supporting IPC for ODP? Should I update IPC patches > on the latest ODP now? > > In the latest IPC patch as I remember IPC was done on pktio level: > a) odp pool is shared between 2 processes with shared consumer/producer > paths for odp_buffer_t descriptors. > 2) producer process adds odp_buffer_t to producer path. > 3) consumer process reads odp_buffer_t from producer path, and translates > it to it's own odp_buffer_t. > 4) After some work consumer thread puts odp_buffer_t to producer path. So > that control of the packet is back to first process and first process can > free this packet from the pool. > > I.e. in fact that exchange between processes is done with odp_buffer_t > handlers and no packet body coping. That is mostly description of software > path, i.e. linux-generic. > > I need ipc for things like snort (single threaded app) and I think that > the same way can be used for virtualization. > > Best regards, > Maxim. > > _______________________________________________ > lng-odp mailing list > [email protected] > http://lists.linaro.org/mailman/listinfo/lng-odp >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
