This is an implementation issue. An implementation may support only pthreads and processes if all resources are setup before the fork. It’s trickier to support separate processes (not forked from a common ODP app process) or processes forked before all resources are setup, but it can be done. The current linux-generic implementation has a broken support for processes (it used to have minimal support and worked with odp_scheduling test). A process support test case (in minimum for processes forked after resource creation) should be added. Carl may have even created a bug for that.
Process mode could be requested with a global init param. For example, in process mode a pktio handle could point to a table of socket fd’s – one for each process, etc. Anyway, first step would be to ensure correct shared mem usage in process mode: allocate everything as shm and make sure that mmap’s result identical virtual -> physical memory mapping. Application uses the API (all handles, etc resources) exactly the same way regardless of the mode: bare metal, pthread, linux process, RTOS process, … If there are gaps in the API (e.g. in the global init phase), we’ll fix those. - Petri From: lng-odp [mailto:[email protected]] On Behalf Of EXT Christophe Milard Sent: Wednesday, December 30, 2015 10:10 AM To: Maxim Uvarov Cc: LNG ODP Mailman List Subject: Re: [lng-odp] pktio with file descriptor used for io and linux processes as ODP tasks... I'll try to be clearer: If a second linux process (ODP task) called B does a pktio_lookup() on a pktio opened by first linux process A (onother ODP task implemented as unix process), it will be returned the pktio_handle that A created, and will start using the file descriptor stored there. B will use the file descriptor created by A. I must be missing something. But that is doomed to fail in my eyes. On 30 December 2015 at 08:57, Maxim Uvarov <[email protected]<mailto:[email protected]>> wrote: On 12/30/2015 10:42, Christophe Milard wrote: My question relates to pktio when ODP tasks are implemented as unix processes (as opposed to threads). I can see that the pktio_entry struct used is allocated as shared mem. If I take the socket pktio as an example, the socket file descriptor is stored in th pktio struct. In other words, the socket file descriptor is shared between all ODP task (i.e. unix processes). This does makes sense only if: 1)The process creating and using the pktio is unique (shared mem is not necessary but won't hurt) 2) the file descriptor is created before fork(), i.e. pktio_open() is performed before ODP threads are created. Always. Are there any rules like this about the pktio handle usage? If a pktio handle is supposed to be reachable at any time by any task (at worse case, a process A creates a pktio handle and passes it to another processes B and C which performs io on the handle opened by A), then It looks like we have a problem... I have a similar situation where a PCI dev (including quite a few file descriptors) is used, and I hoped I could see from the socket example how this is to be handled... but I am not sure... what am I missing...? Thanks, Christophe. Not sure that I understand what exact problem is... In general you should never transmit any odp handle to other process. And task should relay only on return of odp_pktio_open() call. Threads can look up pktio with odp_pktio_t odp_pktio_lookup(const char *dev) call. Of course if you do pktio = odp_pktio_open("eth0") fork(); Than you will have 2 process with same pktio handle value if you print it. That happens that fork() just clones memory of parent process to child. But you can not do another pktio2 = odp_pktio_open("eth1") and transmit it to second process and expect that it will work. The same thing with file and socket descriptors. Maxim.
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
