On Wed, Oct 22, 2014 at 04:36:24PM +0400, Maxim Uvarov wrote: > On 10/22/2014 03:53 PM, Jerin Jacob wrote: > >Some review comments, > > > >1) Any specific reason to choose pktio instead of queue for IPC abstraction ? > > Yes. First versions I did for queues. Refer to ipc v7 patch in mailing list. > After that most everyone complained that it has to be on packet i/o level. > And the main reason for that is that in hardware accelerated packet i/o > communication between different processes has to be easy. I.e. one process > just sends packet to hw and other receives and it's hw deal how to deliver > this packet. In hw case even shared memory is not a requirement.
OK. Make sense. if "non shared memory" is the requirement then PKTIO is the correct abstraction. > > >2) How classification fits into the equation if we choose the IPC through > >pktio ? > >API's like odp_pktio_pmr_cos.. > >for non linux-generic platform, May be we can map loopback port as IPC pktio > >to implement complete ODP pktio capabilities. > >But does application needs such capability ? > >or just a "queue" is fine to meet the use cases ? > > queue has to be fine. classifier is in the same process, where queue is > shared. If we will move classifier to separate odp app then IPC is needed. > If we are abstracting IPC with ODP PKTIO then the platform should implement all the ODP PKTIO capabilities(like attaching to classifier etc). Is my understanding correct ?.if there is any expected limitation on specific usage then we should document. > >3) Currently odp_pktio_open creates the queue and application can get > >the created queues through odp_pktio_outq_getdef. > >Do we really need to introduce new "odp_pktio_outq_setdef" API now ? > > I need somehow to link queue and pktio. I.e. say to queue to use specific > output function. > For that reason I implemented odp_pktio_outq_setdef. I think, you can create the queue in odp_pktio_open and attach it and then expose the queues through odp_pktio_outq_getdef. Other point is the use of hard-cored name like "ipc_pktio" in application IMO its not portable. I think we should have API to enumerate all PKTIO in the given platform along with capabilities(like 10G, IPC) then application can choose the pktio for given capability.There can be a case of multiple IPC PKTIOs in a platform as well. > > >4) Do we really need to introduce new API "odp_shm_lookup_ipc" ? > >Is possible to abstract through existing odp_shm_lookup API ? > > That is good question. Probably we can add some flag to odp_shm_lookup where > to search, in local table or shared memory. > > >5) Assuming pool value == 0 for odp_pktio_open as IPC port is not portable. > >Need to introduce macro or standard name for IPC > I think it might be better to add extend odp_buffer_pool_create: > > odp_buffer_pool_t odp_buffer_pool_create(const char *name, > void *base_addr, uint64_t size, > size_t buf_size, size_t buf_align, > int buf_type) > > provide base_addr as remote_pool_mapped_base address and buf_type as: > ODP_BUFFER_TYPE_IPC > > In that case I will not allocate memory, will link pktio with remote > base_addr. > Will check how is it implementable. > > Will send new version of patch. > > Maxim. > > > > _______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org http://lists.linaro.org/mailman/listinfo/lng-odp
