On 3 June 2015 at 14:31, Benoît Ganne <[email protected]> wrote: > If I use D-BUS or ZeroMQ, I get a socket descriptor. I don't want to >>>> block on this descriptor, my application is likely blocking in >>>> odp_schedule() or polling some queues. I could allocate an event (of >>>> whatever type) and associate that with the socket descriptor. >>>> When the socket can read or written, the event will be enqueued >>>> on some queue (also specified). My application will receive the >>>> notification event and will perform all message operations on the >>>> non-blocking socket. >>>> When no more messages to read or message write would block, the >>>> application re-registers the event and queue. >>>> The only API we would need is: >>>> void odp_notification_register(int sd, odp_event_t evt, >>>> odp_queue_t queue); >>>> Perhaps also a call to unregister the notification, to be used >>>> at termination. This would be a nice and generic design (not only >>>> for this specific use case). But it also seems limited to e.g. >>>> Linux and similar operating systems. What about other operating >>>> environments (e.g. bare metal)? >>>> Would those environments not implement this API? Can we have an >>>> ODP API which only is implemented on some platforms/environments? >>>> >>> > Why not using standard odp_queue_enq() then? >>> I mean, you could create a thread which spin over recv() and enqueue >>> an event with the received message to your queue. In that case your >>> datapath threads would just have to deal with queues the usual way. >>> And this pattern would work with the current API and for any >>> notification mechanism, socket, ZeroMQ, POSIX signals. >>> Any thoughts? >>> >> > I want my worker threads to have full and exclusive control of the >> dataplane CPU's, no time slicing here, no OS invocation at all. Any >> additional threads would have to run on some additional CPU which shares >> memory and queues with the dataplane CPU's. (I suddenly see a use for >> Petri's thread type proposal). Are such CPU's always going to be >> available? >> So I can see other (simpler) solutions but no guaranteed portability >> between different ODP platforms. You people (specifically you users) >> think this is a good trade-off? >> > > I think Petri's proposal could take care of this, along with its new > addition about cpumasks we could have a nice solution. > Regarding portability, you won't necessarily have sockets in bare metal > environment anyway. > In our solution for example, we have those extra CPUs for control-plane, > but you don't have sockets on bare metal (at least for now).
> The only "ODP portable" communication so far is pktio. > Which can always be used as the implementation for a MSGIO API. But for now I will continue my prototyping using a non-worker thread in the dataplane application that interacts with the environment (OS/kernel) and performs any blocking system calls. Incoming messages can be passed as events on queues to the worker threads. I will have to see what works for outgoing messages (sent by the worker threads), possibly the non-worker thread will have to act as an intermediary here as well. > > ben >
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
