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. 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]> 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]> 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]] *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]> >> 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 > >
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
