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) < petri.savolai...@nokia.com> 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:lng-odp-boun...@lists.linaro.org] *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 <maxim.uva...@linaro.org> > 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 lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
