From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) by dpdk.org (Postfix) with ESMTP id 01397CE7 for ; Fri, 10 Jun 2016 11:30:02 +0200 (CEST) Received: by mail-wm0-f42.google.com with SMTP id n184so258652593wmn.1 for ; Fri, 10 Jun 2016 02:30:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=o++AtkFbgQDyRDyrK5fA6MSYTl5id5Umb0PlSdMlIu8=; b=Ntfk5/a9s46Xsh28bBkAFoiUjFDDvaub9szbSSz7Mm06wGCaC9WT4A1PNIAJuHc4+F 4so1sfCMRWtFazfAaEQZDkQmYaJ1RS0koALfHky770+VbnnSh3nuM0AQ70lyF2BNvG8B bmcCLc0DZSIea2Bfsu9NoNDcqqHAKA1JgxNhrBHvjxhU7MBWKkhw1Wa9Sq9ByqzW22jz fLA85cTGONymjzSj9bZefKNwL7GPcMlUjGW7uvOB1oeCJjOjFyc5kGQVSH7zAR9JdVFl mCUkRlPK6KxBRsPXvTz/yvR1JtRPtteZCop5bV08GZaK3m7nNgdzhGKoNB5ixiGgMCq1 p68A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=o++AtkFbgQDyRDyrK5fA6MSYTl5id5Umb0PlSdMlIu8=; b=fP/mqUUjigyd1i8B9OOdPS9ISSaZ9JPcU+NJY7EPbV5CX4Ol8j9H3QjUJCbNihdhnt 4BpH0RYVMcU7ofciVLr0YEQc9LRIx9rs2hI+cOzqg3OvsH8hnxHUVd81brxZXcTnyUl5 +bEdTyWsh4HdnhW1F1+tWvQ5CP3UOVa7M+lqnW5vLo1SwPPYKeLST4UIlmo/iRvejiuf s351FpPQFFF632xI6M/Vgfz+ugCdnoSY16AKhZ7SDLQ3OPkVC5u7OA7Rj4EwAF+AqUmO +MqYbtAOkK2DszZOHVb1QX9UU4cftJSzdlcDGkTCZFyoW6eJ2ATZ3+OI48p58azlXHMK zLYw== X-Gm-Message-State: ALyK8tIxMljiaDziDcpQaIhxEgkn+1t+93m4beO7z1w4q8dRQzsZEGFKbTAYQoTIBICqWU3+ X-Received: by 10.28.176.7 with SMTP id z7mr1662129wme.17.1465551002708; Fri, 10 Jun 2016 02:30:02 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id r3sm34790936wme.24.2016.06.10.02.30.01 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Jun 2016 02:30:01 -0700 (PDT) Date: Fri, 10 Jun 2016 02:30:01 -0700 (PDT) X-Google-Original-Date: Fri, 10 Jun 2016 11:30 +0200 From: Thomas Monjalon To: "Burakov, Anatoly" Cc: David Marchand , dev@dpdk.org, "Gonzalez Monroy, Sergio" , "Yigit, Ferruh" , "Traynor, Kevin" , "pmatilai@redhat.com" Message-ID: <1594485.zPMdI6dQJ2@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: References: <1465481396-23968-1-git-send-email-thomas.monjalon@6wind.com> <1679257.PTMOF8o7eO@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: Fri, 10 Jun 2016 09:30:03 -0000 2016-06-10 09:05, Burakov, Anatoly: > Hi Thomas, > > Just a few notes: > > > 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 problem here is IVSHMEM doesn't allocate the memory from DPDK, it allocates new memory segments by mapping a PCI device. I.e. it doesn't do mallocs, it modifies mem_config and adds memory to DPDK. Can that be done from within a PMD? Everything is possible :) Maybe you just need to add an API to add some memory segments. Other question: why is it so important to register these memory segments in EAL? I think they just need to be known by the ivshmem driver which map some objects on top. > > 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. > > The reason for that hack is that we often need to map several hugepages, and some of those pages could be 2M in size. If you're sharing 1G worth of contiguous memory backed by 2M pages, that's 512 files in the command line in vanilla DPDK, but can be made into one with RTE_EAL_SINGLE_FILE_SEGMENTS, so that QEMU command-line doesn't get overly long. > > So removing this hack, while definitely desired, will adversely affect some use cases, such as using IVSHMEM on platforms where 1G pages aren't supported. Whether we want to go with the effort of supporting those is of course an open question - I personally don't have any data on IVSHMEM userbase. Maybe Kevin/other OVS devs could help me out here :) We can keep supporting 2M pages by having a command line option, instead of the #ifdef RTE_EAL_SINGLE_FILE_SEGMENTS. But as I said, it is not the top priority to remove this hack.