From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) by dpdk.org (Postfix) with ESMTP id C48652BA2 for ; Fri, 10 Jun 2016 14:26:51 +0200 (CEST) Received: by mail-wm0-f50.google.com with SMTP id k204so100001399wmk.0 for ; Fri, 10 Jun 2016 05:26:51 -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=pZdOOUglrkWOfI2f4MP020W6Dc/mY+UvnFKZWGAj7jA=; b=RejGlllHeEr7JXhBkY0Qo2urdZUqE5ryK6CXdL/+nLAz3IIc5JvuE+nYWVant930/3 iBky1ZrOXUrNP+SGiiPOGTqWApY5MGjgFQMX/C0zqWot3ws3Ejlk1WFfYpXNTPUny9Q6 bAEa5iTKcqIX/W4GhwJTVf5Sa2RR0PyEbpV/TTKfPxolf2pSAu8YmwMdatRGLbhiImfJ kWAjQbZmnaAmkwLHi+TGSKGmLOOmDKPYWjqWmE0goX9cJicF9AFNE76Ru3vgy8FZzFUB WuX0syLfY8IObf070y+ArxcoiNxgeTjfiwzryPTCKEU7fgDKddkRNwIkE1cvIDg5NVf4 1/pA== 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=pZdOOUglrkWOfI2f4MP020W6Dc/mY+UvnFKZWGAj7jA=; b=kZ/vhMsq8u89ZpAR+3Oq6swS33TX1ArHL37Hp/aIwwm3g9wJy6eKwYTmrZ0fKzFsjR rNLzsldazECeX+h4Rjx+BuYQCh+yZWW3xMBNlaqn0k/VDl9ER0bx6u3foubeFSXssMXy N/jlw4XFl3ekKf/g/+77Jr6cxTCXrBLDGTfoWuqa/rKQN0FlXah3vScVbatHsuOuQlM6 lHfhOC+DA517Yjha7mn8JvWj2iIKpCPEOHRUk7Tkq5PkwagdcybAUE5kbxWJPRUlD52k qxrfiBtd75uhIp9WzuffgUzYSJezprIjKhQ1ASHtyUxDZDLAkj5u+0yYPcmoj4eZo1AZ zA6Q== X-Gm-Message-State: ALyK8tIrDWNtnUyridg8HC0uHtKUcf3/XQqecChP4jyQWBFkGW6QefJnMWHeNb2QtOCjdBfC X-Received: by 10.28.23.84 with SMTP id 81mr19309332wmx.46.1465561611402; Fri, 10 Jun 2016 05:26:51 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id lr9sm12104952wjb.39.2016.06.10.05.26.50 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Jun 2016 05:26:50 -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 14:26:49 +0200 Message-ID: <1879846.B8CZR7LSLV@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> <4009533.BSYr1qtBke@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 12:26:51 -0000 2016-06-10 12:08, Burakov, Anatoly: > Hi Thomas, > > > 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 > > I've read through that thread, and I don't think anything should be done to support that in IVSHMEM. IVSHMEM library should correctly detect all mapped files, whatever the memory layout on the host side (contiguous, noncontiguous, single file...). On the guest, we're simply adding memzones which we map from a PCI device, so IVSHMEM shouldn't be affected by any changes to how memzones/mempools are allocated (mempools aren't even allowed for use with IVSHMEM). You misunderstood me. I was talking about a rework of RTE_EAL_SINGLE_FILE_SEGMENTS. I just say it must be reworked and it can happen in the discussion of a global rework of the memory allocator. It should not be related to IVSHMEM.