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
