From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 354583237 for ; Tue, 19 Dec 2017 17:09:45 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Dec 2017 08:09:45 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,427,1508828400"; d="scan'208";a="4067075" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.237.220.115]) ([10.237.220.115]) by orsmga008.jf.intel.com with ESMTP; 19 Dec 2017 08:09:42 -0800 To: Stephen Hemminger 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 References: <20171219074635.6c4f656d@xeon-e3> <6d025303-f974-077f-511a-51cd62203925@intel.com> <20171219080622.1c1bd5ca@xeon-e3> From: "Burakov, Anatoly" Message-ID: Date: Tue, 19 Dec 2017 16:09:41 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171219080622.1c1bd5ca@xeon-e3> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [RFC v2 00/23] Dynamic memory allocation for DPDK X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 16:09:46 -0000 On 19-Dec-17 4:06 PM, Stephen Hemminger wrote: > 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. > Well, it _kind of_ redoes malloc in the process as we need to handle holes in the address space, but sure, something like "memory hotplug" would've perhaps been a more suitable name. Thanks for your feedback, it will certainly be taken into account for when an inevitable v1 comes :) -- Thanks, Anatoly