From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 33B16AA35 for ; Wed, 15 Jun 2016 20:16:16 +0200 (CEST) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga102.jf.intel.com with ESMTP; 15 Jun 2016 11:16:14 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,476,1459839600"; d="scan'208";a="122519228" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.237.220.133]) ([10.237.220.133]) by fmsmga004.fm.intel.com with ESMTP; 15 Jun 2016 11:16:13 -0700 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, kevin.traynor@intel.com, pmatilai@redhat.com From: Ferruh Yigit Message-ID: <57619B6C.8080408@intel.com> Date: Wed, 15 Jun 2016 19:16:12 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <1679257.PTMOF8o7eO@xps13> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: Wed, 15 Jun 2016 18:16:16 -0000 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. >