From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH] dropping librte_ivshmem - was log: deprecate history dump Date: Fri, 10 Jun 2016 12:13:22 +0200 Message-ID: <4009533.BSYr1qtBke@xps13> References: <1465481396-23968-1-git-send-email-thomas.monjalon@6wind.com> <1594485.zPMdI6dQJ2@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: David Marchand , "dev@dpdk.org" , "Gonzalez Monroy, Sergio" , "Yigit, Ferruh" , "Traynor, Kevin" , "pmatilai@redhat.com" To: "Burakov, Anatoly" 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) In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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