On 29 April 2015 at 04:51, Benoît Ganne bga...@kalray.eu wrote:
We are also interested by IPC and I also think that pktio is the
way to go.
pktio because it is an already existing concept in ODP we can
potentially piggy back on. But IPC has some differences compared to the
vanilla packet
On 27 April 2015 at 21:23, Bill Fischofer bill.fischo...@linaro.org wrote:
IPCs should be short messages used either as shoulder taps or for brief
communication. If a larger data structure is needed, a pointer to it can be
passed ar s the IPC message,
Sender and receiver would normally not be
On 28 April 2015 at 06:40, Benoît Ganne benoit.ga...@kalray.eu wrote:
We are also interested by IPC and I also think that pktio is the way to go.
pktio because it is an already existing concept in ODP we can potentially
piggy back on. But IPC has some differences compared to the vanilla packet
We are also interested by IPC and I also think that pktio is the
way to go.
pktio because it is an already existing concept in ODP we can
potentially piggy back on. But IPC has some differences compared to the
vanilla packet I/O.
I agree, but we might apply different guarantees and they can
I am also interested in IPC (between control and dataplane) but not for
packets but for messages (so more like buffers). I don't see that these IPC
messages should be parsed and classified like packets and I don't need the
packet_flags.h API either.
However pktio seems like the only abstraction
We are also interested by IPC and I also think that pktio is the way to
go. What is transferred is opaque, it is application-dependent. We think
it will be useful for control plane/data plane communication, but might
also be used to implement pipelines between ODP data-plane processes.
I think
Since nobody replayed on rfc patch I did clean up and splitting it
on several patches.
Please consider this version for review.
Thanks,
Maxim.
Maxim Uvarov (7):
linux-generic: zero params for pool create
api: ipc: shared memory add no create flag
api ipc: update ring with shm proc
