This bit of information can be defined in general term: does all “ODP threads” share all memory or not, etc.
Application has to anyway handle the difference between pthread/processes/etc in the application startup phase, so small difference in odp_global_init or odp_local_init parameters is not a big deal. For portability, it’s important that all other ODP calls behave the same regardless if the caller is pthread/process/etc. -Petri From: EXT Alexandru Badicioiu [mailto:[email protected]] Sent: Monday, January 04, 2016 9:54 AM To: Bill Fischofer Cc: Christophe Milard; LNG ODP Mailman List; Savolainen, Petri (Nokia - FI/Espoo) Subject: Re: [lng-odp] pktio with file descriptor used for io and linux processes as ODP tasks... On 30 December 2015 at 15:44, Bill Fischofer <[email protected]<mailto:[email protected]>> wrote: I think Petri makes a good point. First is that here should be some hint at odp_init_global() time that the application will be using processes vs. threads. Processes/threads are OS dependent so doesn't this approach break the portability? Second, that when process mode is indicated the implementation of odp_pktio_open() may need to change to use an fd table (one per odp application process) rather than a single fd which is shared between all odp threads. But from an application perspective, the odp_pktio_t handle is the same and all pktio APIs behave the same. On Wed, Dec 30, 2015 at 6:00 AM, Christophe Milard <[email protected]<mailto:[email protected]>> wrote: I am confused here: The rules (e.g. order in which different ODP function should be called) and the behaviour (e.g. what is returned by ODP_pktio_lookup()) cannot be implementation dependant. At least not if we wish application to be portable between different ODP implementation... If pktio_open() should be called before any ODP task is created, shouldn't it be written and apply to all ODP implementations? I guess we can take that at some ARCH call... On 30 December 2015 at 10:32, Savolainen, Petri (Nokia - FI/Espoo) <[email protected]<mailto:[email protected]>> wrote: 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]<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]<mailto:[email protected]> https://lists.linaro.org/mailman/listinfo/lng-odp _______________________________________________ lng-odp mailing list [email protected]<mailto:[email protected]> https://lists.linaro.org/mailman/listinfo/lng-odp
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
