From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=Xy9U3aObOFnd5QUss0DyHGAB4DOtQiPwc0csPXikcWM=; b=gY0zhtU4+TiNLZFPc0q4SQVdVoh1kpdRmxYQyevZx8SJkbV1O/U2xCxUbveu2DMnyh CvfbLK0BN+KnllLNlmk4iD2a9NJplQV9zKoZ0lYWzpLil8wzJ3vgJt92ku69dxwM1uEU MNAIL5qyFctf176dASwk9JrW3e0fyRlz0tGqdMg2GZBAYxWZQcRHMwjTtksPY1iC3/7V fv+d39SNsPyu0xDPwH1AW2S9GKbLufDU8rWFePIsIc0Nf/x5bqlrEF6kDF4MZHYzGJOA NJxxsfftk3YyLhDgleAgZgVYMIdZfefFqpxfzWNrabB+deZJt+b1d2WpCthuu07N8yrd Tp7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Xy9U3aObOFnd5QUss0DyHGAB4DOtQiPwc0csPXikcWM=; b=kL1NvWA7eqsNlnGfJewlIvO892fMZa4AxI6Dd5v9qhdR2zAXe61yhLnwJldVW76Ilf ydj/5cJaNbePBFezc2dVwdo5EIWtEiQExut1+7FnuxqwXQgv0KApBbF0aZRRFUHA0rtt RvaQDPQsw+IqS5M3xsebaQ5XRjcqzjWAm0myKSyoqOlWAloXFrvG6y/a8zMyXca2+jMh rT0rZx1NP/BueqW/g4Jcz6szpnJi39MmjxRvk1eZcXVAu2W1Qu/+WliC4BAy55XG5U9X 0MszKkIzAhM2mn3fIk/QBYy6pX9z6cwtRc6nppLe+gdAC1T4tbHztlUG9ACwswE9MmC3 hQVQ== X-Gm-Message-State: AKGB3mK0sJGH0uGdZ7/xLrncmHA8fgqH9ZYUlIlMaUP1eb6ySqwTy35J 6iXV4mP87zU19QnRWFd7kdWyZS6wGwc= X-Google-Smtp-Source: ACJfBotHw9497fgBoGtsOAeR512wwR0K3CtmZwpSRAF22ymGlWhdO6DKPjN71eoB9geKQDzqcj0BoA== X-Received: by 10.98.195.26 with SMTP id v26mr3684321pfg.209.1513699586366; Tue, 19 Dec 2017 08:06:26 -0800 (PST) Received: from xeon-e3 (204-195-18-133.wavecable.com. [204.195.18.133]) by smtp.gmail.com with ESMTPSA id h13sm27896482pfi.40.2017.12.19.08.06.25 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 19 Dec 2017 08:06:26 -0800 (PST) Date: Tue, 19 Dec 2017 08:06:22 -0800 From: Stephen Hemminger To: "Burakov, Anatoly" 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 Message-ID: <20171219080622.1c1bd5ca@xeon-e3> In-Reply-To: <6d025303-f974-077f-511a-51cd62203925@intel.com> 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 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:06:27 -0000 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.