[dpdk-dev] [PATCH] dropping librte_ivshmem - was log: deprecate history dump
pmatilai at redhat.com
Tue Jun 21 08:49:27 CEST 2016
On 06/10/2016 12:26 AM, 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:
> -> 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
> 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.
+1 (more like +100) to that.
In addition to the technical mess in EAL, there are quite some
eyebrow-raisers related to IVSHMEM:
That it all starts with "you'll need to build a special version of qemu"
with this special patch from the 'net, a patch which doesn't even exist
anymore, is a complete non-starter. Such a situation can occur during
early development, but its been years by now. Dependencies to
non-upstreamed features in other projects are not a healthy sign.
Regardless of whether the patch has been integrated to qemu upstream or
not, the situation is quite telling: nobody cares enough to have updated
the information. I found a copy of the patch from my laptop, and as far
as I can tell, the patch has never been proposed upstream, much less
applied. Certainly the patch would not come even close to applying to
current qemu. And apparently IVSHMEM is unmaintained in qemu upstream
too (according to MAINTAINERS).
On DPDK side, that the most obvious (to me at least) user of memnic PMD
has been unmaintained for two years no, and allowed to fall off the edge
of the world (witness http://dpdk.org/browse/memnic/) is also quite telling.
Just deprecate it already. If somebody shows up with actual patches to
clean it all up, the deprecation can be lifted of course, but cleaning
up this abandonware seems like waste of engineering resources to me.
- Panu -
More information about the dev