On 18 May 2015 at 11:55, Maxim Uvarov <[email protected]> wrote:
> > > On 18 May 2015 at 12:00, Ola Liljedahl <[email protected]> wrote: > >> I am prototyping inter-process communication (message passing), primarily >> intended for communication between control and data plane applications. >> >> The linux-generic implementation is based on pktio (a new type >> ODP_PKTIO_TYPE_IPC) and messages are packets, much like Ethernet frames (48 >> bits destination "address", 48 bits source address, 32 bits message type >> followed by user defined payload). >> >> Originally I intended to only see IPC as a form of pktio (on an internal >> network between applications on the same host). But I need to add a few >> functions (e.g. to resolve process "address" by name and to monitor >> processes should they go away). I briefly considered adding these calls to >> packet_io.h but then instead created a new file ipc.h. I was thinking that >> perhaps the IPC API should be separate from packet_io even if the >> implementation is not. >> >> So the basic question is whether IPC/message passing is a completely >> separate API or just a different type of packet IO (doing something similar >> to what the loopback device support did). Comments on this? >> >> -- Ola >> >> >> > > Hello Ola, it looks like you need additional pktio params. I.e. to set dst > and src address to outgoing packets. > But it's not very clear why that can't go to application and we need > separate API for that. It looks like your solution is good for odp helper > (allocate more headroom, set dst and src and blast packet). > If IPC is just another form of pktio (from a user perspective), then the user will be responsible for initialising the message header and writing the destination address (source address might be filled in unconditionally, I don't want an application to be able to spoof the source address) and message type, nothing different from other pktio types. As you say there can be ODP helper functions that simplify life for the programmer. This was my starting point (starting by hacking in the existing code...). But where do I then put the functions that perform name resolution and process monitoring? Are these also packet_io.h calls that will only work with pktio of the IPC type? They will look quite out of place in packet_io.h. Things didn't seem as clear cut anymore... /** * Resolve process by name * * Look up an existing or future process by name. * When the process exists, return the specified message with the process * as the sender. * * @param ipc IPC handle * @param name Name to resolve * @param msg Pointer to message to return * @retval 0 on success * @retval <0 on error */ int odp_ipc_resolve(odp_ipc_t ipc, const char *name, odp_packet_t *msg); /** * Monitor process * * Monitor an existing (potentially already dead) process. * When the process is dead, return the specified message with the process * as the sender. * * @param ipc IPC handle * @param addr Identifier of process * @param msg Pointer to message to return * @retval 0 on success * @retval <0 on error */ int odp_ipc_monitor(odp_ipc_t ipc, const uint8_t addr[6], odp_packet_t *msg); And is it right to conflate IPC with packet io from a conceptual perspective? What about other platforms where IPC might have to be implemented in a very different way, having nothing to do with packet IO? ODP is supposed to be abstract and implementation independent. linux-generic and similar implementations can still implement IPC using the internal pktio framework. > Thank you, > Maxim. > > >> _______________________________________________ >> lng-odp mailing list >> [email protected] >> https://lists.linaro.org/mailman/listinfo/lng-odp >> >> >
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
