From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id 069402142 for ; Thu, 9 Jun 2016 23:26:26 +0200 (CEST) Received: by mail-wm0-f47.google.com with SMTP id m124so77264141wme.1 for ; Thu, 09 Jun 2016 14:26:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=tgcJ/RmY25s7Oqh5y/1vBQ69aYUh6mmurMHQoj7kYYU=; b=Dh5vsFM1XFGV8UODWiBznhkZjWMJYbP7B2MDdz1RxAI3gaOZVHlvDZoxVJ86c4Nzpf waAIoAQ3MVSlaaMBUjkQGDPIRdFMFIneuR0dmOTw4uGNLzBBT8xixUO9DxSV6zy4sjhp 0DDrbYMjkZfigAk2bSaYmHC9Uh9rcCf+fqTcPGZC1KNZgLa8+oI9R5J8u/KATMrbGPxu sFtP7g1M6uHzlnpH7OTc9o3VgIp10oQO9HpHFJg300rnJ3XqnDaahiDTWYfSWXNWBuN/ I9CHbExPtjedMzzFr/Gb5Oa4k/rIxr1NRlGyV++2hLyeYfYHtiSrxD/a2ed2p/1Pz10o 03CA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=tgcJ/RmY25s7Oqh5y/1vBQ69aYUh6mmurMHQoj7kYYU=; b=iX0R67av4AK9QdurpYn/w+cHPZ/F2Ec6pFD5GLBsb8FtHqg1kV8wvoombr6td3Pq1e qEhdL4HwSO9r9cv53JNEgnlSfCR3REt72N6akzu1EuvfXEYJzO8+HUcBZqscT9jWlrij VFNgFH5cUjPWaqpiGYQz7C1hZQ9uYRi0w1Z1SKb1csAWvvsjw3BTKzu0k76jOH0oo2pW jD54MWFF+4bopzB/0sUIBR1x8AkdUmT42igYd5tz9CGx+2zM0rJVvn1QMBa4QS0jgnOR qMAHeJs9pbNqlv0u2/doSCBxp7YvyOEgK7XmdjoWNkF7vKD7OEIghf4qqfd9nfjUdDwH E3gQ== X-Gm-Message-State: ALyK8tIrsEwwKJ8FRlXhrENBhZIIUzG4rwbCLwFO8TviyjdPfyTfG1yXsIcsAVZvGyHY+Meh X-Received: by 10.28.195.131 with SMTP id t125mr11317244wmf.25.1465507585699; Thu, 09 Jun 2016 14:26:25 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id x128sm7003516wmf.6.2016.06.09.14.26.24 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Jun 2016 14:26:24 -0700 (PDT) From: Thomas Monjalon To: Anatoly Burakov Cc: David Marchand , dev@dpdk.org, sergio.gonzalez.monroy@intel.com, ferruh.yigit@intel.com, kevin.traynor@intel.com, pmatilai@redhat.com Date: Thu, 09 Jun 2016 23:26:23 +0200 Message-ID: <1679257.PTMOF8o7eO@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <1799099.25AIKSsmQj@xps13> References: <1465481396-23968-1-git-send-email-thomas.monjalon@6wind.com> <1799099.25AIKSsmQj@xps13> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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: Thu, 09 Jun 2016 21:26:26 -0000 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. We already talked about the rte_ivshmem design issues several times and nobody declared using it. ---- original thread for reference ---- 2016-06-09 17:01, Thomas Monjalon: > 2016-06-09 16:45, David Marchand: > > - Since you are looking at this, what keeps us from removing the > > dependency on librte_ring ? > > Please see this first small cleanup: > http://dpdk.org/ml/archives/dev/2016-June/040798.html > > > I would say it was mainly because of mempool. > > Maybe ivshmem ? > > Yes CONFIG_RTE_LIBRTE_IVSHMEM brings dependencies to rte_ring and rte_ivshmem. > This "feature" also pollute the memory allocator and makes rework harder. > That's why I would be in favor of removing CONFIG_RTE_LIBRTE_IVSHMEM. > > Otherwise, as an alternative proposal, the file > lib/librte_eal/linuxapp/eal/eal_ivshmem.c > could be moved outside of EAL. Probably that lib/librte_ivshmem/ > would be a good place. > The tricky operation would be to remove ivshmem init from eal: > > #ifdef RTE_LIBRTE_IVSHMEM > if (rte_eal_ivshmem_init() < 0) > rte_panic("Cannot init IVSHMEM\n"); > #endif > > if (rte_eal_memory_init() < 0) > rte_panic("Cannot init memory\n"); > > /* the directories are locked during eal_hugepage_info_init */ > eal_hugedirs_unlock(); > > if (rte_eal_memzone_init() < 0) > rte_panic("Cannot init memzone\n"); > > if (rte_eal_tailqs_init() < 0) > rte_panic("Cannot init tail queues for objects\n"); > > #ifdef RTE_LIBRTE_IVSHMEM > if (rte_eal_ivshmem_obj_init() < 0) > rte_panic("Cannot init IVSHMEM objects\n"); > #endif