From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: [RFC v2 00/23] Dynamic memory allocation for DPDK Date: Tue, 19 Dec 2017 08:06:22 -0800 Message-ID: <20171219080622.1c1bd5ca@xeon-e3> References: <20171219074635.6c4f656d@xeon-e3> <6d025303-f974-077f-511a-51cd62203925@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org, andras.kovacs@ericsson.com, laszlo.vadkeri@ericsson.com, keith.wiles@intel.com, benjamin.walker@intel.com, bruce.richardson@intel.com, thomas@monjalon.net To: "Burakov, Anatoly" Return-path: Received: from mail-pf0-f196.google.com (mail-pf0-f196.google.com [209.85.192.196]) by dpdk.org (Postfix) with ESMTP id 6CFF3160 for ; Tue, 19 Dec 2017 17:06:27 +0100 (CET) Received: by mail-pf0-f196.google.com with SMTP id j124so11306686pfc.2 for ; Tue, 19 Dec 2017 08:06:27 -0800 (PST) In-Reply-To: <6d025303-f974-077f-511a-51cd62203925@intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, 19 Dec 2017 16:02:51 +0000 "Burakov, Anatoly" wrote: > On 19-Dec-17 3:46 PM, Stephen Hemminger wrote: > > On Tue, 19 Dec 2017 11:14:27 +0000 > > Anatoly Burakov wrote: > > > >> This patchset introduces a prototype implementation of dynamic memory allocation > >> for DPDK. It is intended to start a conversation and build consensus on the best > >> way to implement this functionality. The patchset works well enough to pass all > >> unit tests, and to work with traffic forwarding, provided the device drivers are > >> adjusted to ensure contiguous memory allocation where it matters. > > > > > > What exact functionality is this patchset trying to enable. > > It isn't clear what is broken now. Is it a cleanup or something that > > is being motivated by memory layout issues? > > > > Hi Stephen, > > Apologies for not making that clear enough in the cover letter. > > The big issue this patchset is trying to solve is the static-ness of > DPDK's memory allocation. I.e. you reserve memory on startup, and that's > it - you can't allocate any more memory from the system, and you can't > free it back without stopping the application. > > With this patchset, you can do exactly that. You can basically start > with zero memory preallocated, and allocate (and free) as you go. For > example, if you apply this patchset and run malloc autotest, after > startup you will have used perhaps a single 2MB page. While the test is > running, you are going to allocate something to the tune of 14MB per > socket, and at the end you're back at eating 2MB of hugepage memory, > while all of the memory you used for autotest will be freed back to the > system. That's the main use case this patchset is trying to address. > > Down the line, there are other issues to be solved, which are outlined > in the cover letter (the aforementioned "discussion points"), but for > this iteration, dynamic allocation/free of DPDK memory is the one issue > that is being addressed. > Ok, maybe name it "memory hot add/remove" since dynamic memory allocation to me implies redoing malloc.