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

[Ferruh Yigit <ferruh.yigit@intel.com>]

On 6/9/2016 10:26 PM, Thomas Monjalon wrote:
> 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.

I would like to note that at least SPP (soft patch panel) is using
rte_ivshmem feature.

> We already talked about the rte_ivshmem design issues several times
> and nobody declared using it.
>