I don't mint the hint. Neither do I mind the different implementation,as long as they behave the same. But (at least as far as I can see from the code): 1)There is a requirement on the order things are done which differs depending on how threads are implemented (i.e. pktio_open() should preceed all ODP task creation (fork()) when tasks are processes) 2)Some functions do not behave the same depending on how tasks are created (pktio_lookup() will see pktios created by other tasks if they are thread. it wont in the case they are processes.
PS, Bill: I originally thought that pktio entries were shared between processes: this does not seem to be the case: shm_reserve is called with no flag, hence creating anonymous mapping, which will propagate with fork, but won't be visible between linux processes: It is therefore more legitimate to store file descriptors in the pktio entries, but raises more question regarding the meaning of the pktio_lookup function and the sharing of pktio ressource.) On 30 December 2015 at 14:44, Bill Fischofer <[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. 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
