On 03/13/15 13:43, Ciprian Barbu wrote:
On Fri, Mar 13, 2015 at 11:34 AM, Ola Liljedahl
<[email protected]> wrote:
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?
I agree with Ola here. The problem you have seems to only apply to
linux-generic, on some real HW platforms it should be possible to
"transfer" packets from one process to another trough globally visible
queue ids, indistinctly from the two entities being different ODP
applications or different threads of the same ODP application.
I think we need to first define better the visibility scope of pools
and queues for ODP in general and see how it applies to linux-generic
in particular. If needed linux-generic should make the queue ids and
buffer ids globally visible transparently, not necessarily with best
performance, the ODP design should first and foremost be clear and
linux-generic is a reference software implementation.
As for IPC, as Ola said, it should be a service that provides a form
of communication framework between different ODP "workers", with the
possibility of being able to synchronize on different message types.
ENEA has had an IPC framework for a long time that works this way and
provides transparent, reliable, scalable IPC, not only between
processes on the same system, but between different nodes in a
network. The protocol is even open sourced and available for Linux
distributions. I think at the very least ODP should incorporate some
of the design aspects, like for example defining new event types to be
used for IPC and define an IPC API for exchanging messages between the
different ODP instances.
/Ciprian
Actually I do not understand the reason of that "messages". And why it
has to be in ODP.
Say for example if you have some odp packet and you want to send it to
other node, just
do it in software. Hardware here can not help you.
I understand my use case. It it to have best performance on exchanging
packets between different
processes which can share memory on the same machine. Taras some time
ago said that if that
sort of IPC will be on pktio level then TI KS2 can do exchanging packets
in hardware not related if
it's same pool or not. One of initial version of patch was bases on
queue abstraction, while after
we decided to go with pktio abstraction.
If I understand right Ola and Ciprian speak more about connection
protocol between data plane and control plane.
That is not IPC, as I see this. It's connection protocol. IPC is for
communication on the same node between different processes.
btw, did you review proposal patches? There is also test application
which send back and forth odp packets.
http://lists.linaro.org/pipermail/lng-odp/2014-November/004525.html
http://lists.linaro.org/pipermail/lng-odp/2014-November/004526.html
Maxim.
-- 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
_______________________________________________
lng-odp mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/lng-odp
