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. >
