On 2 September 2015 at 14:53, Maxim Uvarov <maxim.uva...@linaro.org> wrote:
> On 09/02/15 14:11, Alexandru Badicioiu wrote: > >> Hi Maxim, >> I think we need a real spec, maybe API extension for IPC pktio to be >> extendable to platforms with HW acceleration, otherwise it will be just a >> linux generic implementation feature. The test application cannot be a >> itself a spec. >> > > yes, I agree. But we need to start from some point. Might be having > linux-generic as reference will help to speed up this process. On Connect > hacking session we can try to prototype api which is good for everybody. > > I think the following assumptions cannot be imposed or work in all cases >> in a HW accelerated environment, various operating environments, etc: >> - IPC pktio requires processes with a direct parent - child relationship >> > > there will be always direct parent. At least odp app will be different for > parent and children. [Alex] I'm not sure this is the right thing to impose. Two ODP apps should be able to exchange packets over a pktio interface even if they are not parent-child (e.g. both apps are launched from the same shell - siblings?). > > > - a packet pool is by default shared between two ODP >> processes/applications (one creates a packet pool, the other gets it by >> name) >> > > That is linux-generic only to have be zero copy speed up. In hardware > accelerated case it might be different pools. [Alex] This would be reflected at least in the way the API is used - right now one app opens ipc pktio with a pool argument, the other with INVALID pool. In this case I think the pool must be explicitly created as shared in this case. If the pool is not shared the second app should open the pktio with another valid pool and the implementation should address the case (by doing DMA copies for example). Creating hidden pools in the implementation may be problematic - how the implementation is supposed to know how big the pool should be, etc - this is application knowledge. > > > - memory backing up a packet pool created by an application can always be >> mapped in other application memory space >> >> > that is hidden inside current linux-generic implementation. If you don't > need use shared memory for packet exchange - not use it. > [Alex] This leads to ambiguity for implementation - if an application > opens an IPC pktio with an INVALID pool how the implementation knows what > to do - try to map the pool used by the other app when opened the IPC > pktio, create a new pool, etc > Maxim. > > Thanks, >> Alex >> >> >> >> >> On 31 August 2015 at 13:48, Maxim Uvarov <maxim.uva...@linaro.org >> <mailto:maxim.uva...@linaro.org>> wrote: >> >> On 08/31/15 12:05, Alexandru Badicioiu wrote: >> >> Hi Maxim, >> I'd ask some questions related to the testing application: >> >> https://git.linaro.org/people/maxim.uvarov/odp.git/blob/8c749b3fd6e0a3715e06c262d85244aa180dd204:/platform/linux-generic/test/pktio_ipc/pktio_ipc.c >> which probably shows how an IPC pktio would be typically used : >> >> - is "ipc_pktio" the solely id for an IPC pktio ? Is it >> possible to have more than 1 IPC pktio ? Is the IPC pktio >> meant for 1 to 1 duplex data exchange? >> >> >> For now it's only linux-generic specific ipc pktio. You can open >> several pktios odp_pktio_open("ipc_1", ), odp_pktio_open("ipc_2", >> ), odp_pktio_open("ipc_3", ) and etc. >> All of them represented as shared memory. Second process can >> connect to that ipc_2, ipc_2. Several slave processes can connect >> to one ipc_1 for example. So >> it's duplex exchange over several processes where one of the >> process has to be master (to create shared memory blocks.). >> >> >> - it looks like the implicit assumption is that the pool >> created by the main process and used to open IPC pktio is >> shared automatically with the child process as the child >> process is able to copy data from the packet it receives from >> IPC pktio >> >> The plan was to not modify API, in that case pool is shared >> automatically. Slave process copies packet in recv() to not handle >> in it. When packet reference counters will be implemented then we >> can avoid this coping and simple reference to packet memory of >> another process. Because of linux-generic is not performance >> critical I will postpone that tunning. >> >> - there is a comment mentioning a "local pool" for the child >> process but I can't find any reference to it in the >> application code - is it something that is supposed to be >> hidden into implementation? >> >> >> Yes, that is hided. First process needs access to second process >> packets also. And that is done in way that second process creates >> the same pool as master (i.e. same parameters like number and size >> of segments). Then second pool is mapped to first process. Because >> original plan was to now modify api, reference to that pool is >> hided inside implementation. >> >> Maxim. >> >> >> Thanks, >> Alex >> >> >> >> >> On 31 August 2015 at 11:11, Maxim Uvarov >> <maxim.uva...@linaro.org <mailto:maxim.uva...@linaro.org> >> <mailto:maxim.uva...@linaro.org >> >> <mailto:maxim.uva...@linaro.org>>> wrote: >> >> ping. >> >> On 08/18/15 14:01, Maxim Uvarov wrote: >> >> v8: - make pktio ipc internal pktio for linux-generic; >> - place validation test for pktio ipc inside >> linux-generic; >> - move odp_ring and odp_pause from helpers inside >> linux-generic; >> - cleanup checkpatch errors in ring code. >> >> v7: - 1. do pool_create things more accurate. Pass shm >> flags >> internal where is needed. >> Do not allocate shm before because Bill already >> posted >> patch to remove shm from >> odp_pool_create. >> 2. Rework example application: remove time >> stamps. Add >> sequence counter and magic >> numbers, print packets per second. >> >> v6: Fix Ciprian comments for v5: >> - update patches to current HEAD; >> - fix segfault on cold start (not share >> schedule pool); >> - rename rings name to better understanding; >> - comment variables in the code; >> - update code to new checkpatch.pl >> <http://checkpatch.pl> <http://checkpatch.pl>; >> Fix Ola's comment to not use sleep() in example. >> >> >> Maxim Uvarov (12): >> linux-generic: zero params for pool create >> api ipc: update ring with shm proc argument >> linux-generic: create internal pool create function >> with >> shm flags >> move odph_pause inside linux-generic >> helper: flag to not link ring to linked list >> linux-generic: move odp_ring from helper to >> linux-generic >> platfrom >> linux-generic: rename odph_ring.., to shm_ring... >> linux-generic: ring: remove ODPH_ prefix >> linux-generic: rename to ring >> linux-generic: ring_test.c fix code style errors >> linux-generic: add ipc pktio support >> linux-generic: internal ipc_pktio test >> >> configure.ac <http://configure.ac> <http://configure.ac> >> | 1 - >> >> >> helper/Makefile.am | 8 +- >> helper/test/Makefile.am | 4 +- >> helper/test/odph_pause.c | 14 - >> platform/linux-generic/Makefile.am | 3 + >> .../linux-generic/include/odp_buffer_internal.h | 3 + >> .../linux-generic/include/odp_packet_io_internal.h | 33 ++ >> .../include/odp_packet_io_ipc_internal.h | 51 ++ >> .../linux-generic/include/odp_pause_internal.h | 0 >> platform/linux-generic/include/odp_pool_internal.h | 4 + >> .../linux-generic/include/odp_ring_internal.h | 88 +-- >> platform/linux-generic/include/odp_shm_internal.h | 20 + >> platform/linux-generic/m4/configure.m4 | 4 +- >> platform/linux-generic/odp_packet_io.c | 1 + >> platform/linux-generic/odp_pool.c | 22 +- >> platform/linux-generic/odp_schedule.c | 4 +- >> platform/linux-generic/odp_shared_memory.c | 10 +- >> platform/linux-generic/pktio/io_ops.c | 1 + >> platform/linux-generic/pktio/ipc.c | 629 >> +++++++++++++++++++++ >> {helper => platform/linux-generic/pktio}/ring.c | >> 190 ++++--- >> platform/linux-generic/test/Makefile.am | 4 +- >> platform/linux-generic/test/pktio_ipc/.gitignore | 1 + >> platform/linux-generic/test/pktio_ipc/Makefile.am | 11 + >> platform/linux-generic/test/pktio_ipc/pktio_ipc.c | 595 >> +++++++++++++++++++ >> .../linux-generic/test/pktio_ipc/pktio_ipc_run | 68 +++ >> platform/linux-generic/test/ring/.gitignore | 1 + >> platform/linux-generic/test/ring/Makefile.am | 14 + >> .../linux-generic/test/ring}/odp_common.c | 0 >> .../linux-generic/test/ring}/odp_common.h | 0 >> .../linux-generic/test/ring/ring_test.c | 109 ++-- >> test/Makefile.am | 2 +- >> test/api_test/.gitignore | 2 - >> test/api_test/Makefile.am | 13 - >> test/validation/queue/queue.c | 1 + >> 34 files changed, 1671 insertions(+), 240 deletions(-) >> delete mode 100644 helper/test/odph_pause.c >> create mode 100644 >> platform/linux-generic/include/odp_packet_io_ipc_internal.h >> rename helper/odph_pause.h => >> platform/linux-generic/include/odp_pause_internal.h (100%) >> rename helper/include/odp/helper/ring.h => >> platform/linux-generic/include/odp_ring_internal.h (87%) >> create mode 100644 >> platform/linux-generic/include/odp_shm_internal.h >> create mode 100644 platform/linux-generic/pktio/ipc.c >> rename {helper => >> platform/linux-generic/pktio}/ring.c (74%) >> create mode 100644 >> platform/linux-generic/test/pktio_ipc/.gitignore >> create mode 100644 >> platform/linux-generic/test/pktio_ipc/Makefile.am >> create mode 100644 >> platform/linux-generic/test/pktio_ipc/pktio_ipc.c >> create mode 100755 >> platform/linux-generic/test/pktio_ipc/pktio_ipc_run >> create mode 100644 >> platform/linux-generic/test/ring/.gitignore >> create mode 100644 >> platform/linux-generic/test/ring/Makefile.am >> rename {test/api_test => >> platform/linux-generic/test/ring}/odp_common.c (100%) >> rename {test/api_test => >> platform/linux-generic/test/ring}/odp_common.h (100%) >> rename test/api_test/odp_ring_test.c => >> platform/linux-generic/test/ring/ring_test.c (80%) >> delete mode 100644 test/api_test/.gitignore >> delete mode 100644 test/api_test/Makefile.am >> >> >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org> >> <mailto:lng-odp@lists.linaro.org >> <mailto:lng-odp@lists.linaro.org>> >> https://lists.linaro.org/mailman/listinfo/lng-odp >> >> >> >> >> >
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
