Re: [dpdk-dev] [PATCH] dropping librte_ivshmem - was log: deprecate history dump

[Thomas Monjalon <thomas.monjalon@6wind.com>]

Looking a bit more into librte_ivshmem, the documentation says we need
a Qemu patch but the URL doesn't exist anymore:
	https://01.org/packet-processing/intel%C2%AE-ovdk
	-> 404 Oops, we couldn't find that page

I've never understood why we should keep this wart and now I'm going
to be upset.
To sum up the situation, eal depends on ivshmem which depends on
ring/mempool which depends... on eal.
The truth is that eal should not depends on librte_ivshmem.
And the option CONFIG_RTE_LIBRTE_IVSHMEM should not exist.

There are 3 parts to distinguish:

1/ The librte_ivshmem API to export some data structures from host.
No real problem here.

2/ The scan of the ivshmem devices in the guest init.
It should be handled as any other PCI device with an appropriate driver.
The scan is done by rte_eal_pci_init.

3/ The automatic mapped allocation of DPDK objects in the guest.
It should not be done in EAL.
An ivshmem driver would be called by rte_eal_dev_init.
It would check where are the shared DPDK structures, as currently done
with the IVSHMEM_MAGIC (0x0BADC0DE), and do the appropriate allocations.
Thus only the driver would depend on ring and mempool.

The last step of the ivshmem cleanup will be to remove the memory hack
RTE_EAL_SINGLE_FILE_SEGMENTS. Then CONFIG_RTE_LIBRTE_IVSHMEM could be
removed.

So this is my proposal:
Someone start working on the above cleanup now, otherwise the whole
rte_ivshmem feature will be deprecated in 16.07 and removed in 16.11.
We already talked about the rte_ivshmem design issues several times
and nobody declared using it.


---- original thread for reference ----

2016-06-09 17:01, Thomas Monjalon:
> 2016-06-09 16:45, David Marchand:
> > - Since you are looking at this, what keeps us from removing the
> > dependency on librte_ring ?
> 
> Please see this first small cleanup:
> 	http://dpdk.org/ml/archives/dev/2016-June/040798.html
> 
> > I would say it was mainly because of mempool.
> > Maybe ivshmem ?
> 
> Yes CONFIG_RTE_LIBRTE_IVSHMEM brings dependencies to rte_ring and rte_ivshmem.
> This "feature" also pollute the memory allocator and makes rework harder.
> That's why I would be in favor of removing CONFIG_RTE_LIBRTE_IVSHMEM.
> 
> Otherwise, as an alternative proposal, the file
> 	lib/librte_eal/linuxapp/eal/eal_ivshmem.c
> could be moved outside of EAL. Probably that lib/librte_ivshmem/
> would be a good place.
> The tricky operation would be to remove ivshmem init from eal:
> 
> #ifdef RTE_LIBRTE_IVSHMEM
>     if (rte_eal_ivshmem_init() < 0)                                                                              
>         rte_panic("Cannot init IVSHMEM\n");
> #endif
> 
>     if (rte_eal_memory_init() < 0)
>         rte_panic("Cannot init memory\n");
> 
>     /* the directories are locked during eal_hugepage_info_init */
>     eal_hugedirs_unlock();
> 
>     if (rte_eal_memzone_init() < 0)
>         rte_panic("Cannot init memzone\n");
> 
>     if (rte_eal_tailqs_init() < 0)
>         rte_panic("Cannot init tail queues for objects\n");
> 
> #ifdef RTE_LIBRTE_IVSHMEM
>     if (rte_eal_ivshmem_obj_init() < 0)
>         rte_panic("Cannot init IVSHMEM objects\n");
> #endif