From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) by dpdk.org (Postfix) with ESMTP id ECB262A5F for ; Fri, 10 Jun 2016 12:13:24 +0200 (CEST) Received: by mail-wm0-f51.google.com with SMTP id k204so95445243wmk.0 for ; Fri, 10 Jun 2016 03:13:24 -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=me0VoN7AIDoo3jXZRn/et3MRtoaGeOiwXOBqJQV6brQ=; b=oSIPIeQqZ5JceNY0LDjoNwk7ZdCU0TZJOyriv2SUI7ldOkbOWxm3DIFRN14DadX1eE zdxIuoRy13ge+Tym/xAYcsCIpQAWvxKCO5tl7nmYTKSeCj1UcvS/MBItEFVHm4C1AwlF 13fH3Xaib9tzdIkFxEJH+FIi9ebt5qwDpJIs04XLx9x1OshwKQdE82Hg2/9xKEpPd4aJ ES6GoYUJT5RW4m7S6KWYkTpCHmyIZRlnbp6jUfprhovaHQoNWh1r1ift/pFCd30P24HR lcWjxJpeEG1x/Gwz4mz01NDAaVF2i9tZMO4WwVBoJKYqqZJBc+qV/RETUnHpqGYkuCtF VYjA== 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=me0VoN7AIDoo3jXZRn/et3MRtoaGeOiwXOBqJQV6brQ=; b=LUQo8ltaRPBkFFL+p3ItWgEgaoTl1Wg8l8khUkOnwo3coWeL5NOlII2US0YnxrLKNt ZUwZzQrZSc6BotaT0gLx4SgyK3NvSLTDPftJRsZjYEhJSYdFQrgIq8d/2Dt3UNZGifV0 hKnr5SmYiZ3Qn6iB5qdJhIeXxDSqdlSJmTlCuaLrPjQyN2PxJvmKm9QQMv0MkvVmhcGi DXfjB9778AMBgwYymSbxCZGqjFvhcaXJqs0F1EFc6ZNBV9AyfDHMLORiqdOF47bFNHpb uBK0ygIP5DVoPRnUsodqzcCclOYwoD6rEk8Y9BcekHU3GdkScMSTPOLdKoI0RLaN+H6L e6MA== X-Gm-Message-State: ALyK8tK048hZaoofMrUIJEpG1vo+l43M393yzHUo4EbciscvxEpryTLJMib9yK0DQ9KTsNxc X-Received: by 10.28.3.70 with SMTP id 67mr18303263wmd.32.1465553604705; Fri, 10 Jun 2016 03:13:24 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id c191sm34962970wmh.5.2016.06.10.03.13.23 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Jun 2016 03:13:23 -0700 (PDT) From: Thomas Monjalon To: "Burakov, Anatoly" Cc: David Marchand , "dev@dpdk.org" , "Gonzalez Monroy, Sergio" , "Yigit, Ferruh" , "Traynor, Kevin" , "pmatilai@redhat.com" Date: Fri, 10 Jun 2016 12:13:22 +0200 Message-ID: <4009533.BSYr1qtBke@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> <1594485.zPMdI6dQJ2@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 10:13:25 -0000 2016-06-10 09:47, Burakov, Anatoly: > > > > 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. > > Ah, so you're not suggesting removing the _functionality_, just the #ifdef? That could be made to work I guess... > > Also, please correct me if I'm wrong, but I seem to remember some patches about putting all memory in a single file - I think that should work for IVSHMEM as well, because I believe IVSHMEM handles holes in files just fine, and can map even if everything resides inside a single file. So if that patch does what I think it does, we might just integrate it and remove the single file segments code entirely. Yes it can be considered in a memory allocator rework. Please jump in this thread: http://dpdk.org/ml/archives/dev/2016-April/037444.html