On 11/06/2014 02:59 PM, Savolainen, Petri (NSN - FI/Espoo) wrote:
+int lg_odp_pktio_lookup(const char *dev, pktio_entry_t *pktio_entry)
>+{
>+ int ret = -1;
>+ char ipc_shm_name[ODPH_RING_NAMESIZE];
>+ size_t ring_size;
>+
>+ if (!(lg_odp_shm_lookup_pktio(dev) == 0 &&
>+ odp_shm_lookup_ipc("shm_packet_pool") == 0)) {
>+ ODP_DBG("pid %d unable to find ipc object: %s.\n",
>+ getpid(), dev);
>+ goto error;
>+ }
So, the role of the new odp_shm_lookup_ipc() call is just check if a shm has
been created. I'm against adding xxx_ipc() versions of existing API calls. You
should be able to just use the normal lookup. Maybe ODP (global init) needs to
be informed that application runs in multi-process mode, so that ODP internal
data structures are mapped so that multiple processes can lookup from those.
For linux-generic I definitely don't need any flag to global init. And
dpdk uses some option only for test app. If we started to do IPC over
PKTIO then we should be flexible. You never know which pool was created
in other process and which pool you want to request. So I think it's
right solution to go with odp_pktio_lookup().
And implementation of odp_pktio_lookup() might be different of course.
If you check e.g. "Multi-process Sample Application" chapter in DPDK sample
apps guide. It gives a cleaner framework how to handle the multi-process case.
I did not see that before you pointed to me. Now I read this:
http://dpdk.org/doc/intel/dpdk-sample-apps-1.7.0.pdf
And I would say that my implementation is the same. I.e. what is hided
in odp_pktio_lookup() - 2 software shared memory queues and shared pool
is the same
as dpdk solution. We discussed that our abstraction level is pktio. So
everything should be under it.
Do you know something what I don't ?
Thanks,
Maxim.
_______________________________________________
lng-odp mailing list
lng-odp@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/lng-odp
