From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 172A7324D for ; Tue, 19 Dec 2017 17:02:54 +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 fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Dec 2017 08:02:54 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,427,1508828400"; d="scan'208";a="4065425" 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:02:51 -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> From: "Burakov, Anatoly" Message-ID: <6d025303-f974-077f-511a-51cd62203925@intel.com> Date: Tue, 19 Dec 2017 16:02:51 +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: <20171219074635.6c4f656d@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:02:55 -0000 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. -- Thanks, Anatoly