From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 0480F6CD3 for ; Tue, 21 Jun 2016 08:49:31 +0200 (CEST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 11FD41176BA; Tue, 21 Jun 2016 06:49:30 +0000 (UTC) Received: from sopuli.koti.laiskiainen.org (vpn1-6-229.ams2.redhat.com [10.36.6.229]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u5L6nRVK015754; Tue, 21 Jun 2016 02:49:28 -0400 To: Thomas Monjalon , Anatoly Burakov References: <1465481396-23968-1-git-send-email-thomas.monjalon@6wind.com> <1799099.25AIKSsmQj@xps13> <1679257.PTMOF8o7eO@xps13> Cc: David Marchand , dev@dpdk.org, sergio.gonzalez.monroy@intel.com, ferruh.yigit@intel.com, kevin.traynor@intel.com From: Panu Matilainen Message-ID: <32cac2a1-f918-861c-5e80-622268dcd318@redhat.com> Date: Tue, 21 Jun 2016 09:49:27 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <1679257.PTMOF8o7eO@xps13> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 21 Jun 2016 06:49:30 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH] dropping librte_ivshmem - was log: deprecate history dump X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2016 06:49:31 -0000 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 -