DPDK patches and discussions
 help / color / mirror / Atom feed
From: Panu Matilainen <pmatilai@redhat.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>,
	Anatoly Burakov <anatoly.burakov@intel.com>
Cc: David Marchand <david.marchand@6wind.com>,
	dev@dpdk.org, sergio.gonzalez.monroy@intel.com,
	ferruh.yigit@intel.com, kevin.traynor@intel.com
Subject: Re: [dpdk-dev] [PATCH] dropping librte_ivshmem - was log: deprecate history dump
Date: Tue, 21 Jun 2016 09:49:27 +0300	[thread overview]
Message-ID: <32cac2a1-f918-861c-5e80-622268dcd318@redhat.com> (raw)
In-Reply-To: <1679257.PTMOF8o7eO@xps13>

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

Good :)

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

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

  parent reply	other threads:[~2016-06-21  6:49 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-09 14:09 [dpdk-dev] [PATCH] " Thomas Monjalon
2016-06-09 14:45 ` David Marchand
2016-06-09 15:01   ` Thomas Monjalon
2016-06-09 21:26     ` [dpdk-dev] [PATCH] dropping librte_ivshmem - was " Thomas Monjalon
2016-06-10  9:05       ` Burakov, Anatoly
2016-06-10  9:30         ` Thomas Monjalon
2016-06-10  9:47           ` Burakov, Anatoly
2016-06-10 10:13             ` Thomas Monjalon
2016-06-10 12:08               ` Burakov, Anatoly
2016-06-10 12:26                 ` Thomas Monjalon
2016-06-15 18:16       ` Ferruh Yigit
2016-06-15 18:34         ` [dpdk-dev] [PATCH] dropping librte_ivshmem Thomas Monjalon
2016-06-20 15:44           ` Ferruh Yigit
2016-06-20 15:54             ` Thomas Monjalon
2016-06-21  6:49       ` Panu Matilainen [this message]
2016-06-09 15:01   ` [dpdk-dev] [PATCH] log: deprecate history dump Christian Ehrhardt
2016-06-09 15:06 ` [dpdk-dev] [PATCH v2] " Thomas Monjalon
2016-06-09 22:10   ` [dpdk-dev] [PATCH v3] " Thomas Monjalon
2016-06-10  9:50     ` David Marchand
2016-06-10 13:09       ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=32cac2a1-f918-861c-5e80-622268dcd318@redhat.com \
    --to=pmatilai@redhat.com \
    --cc=anatoly.burakov@intel.com \
    --cc=david.marchand@6wind.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=kevin.traynor@intel.com \
    --cc=sergio.gonzalez.monroy@intel.com \
    --cc=thomas.monjalon@6wind.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).