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.
ben _______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
