From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Gonzalez Monroy, Sergio" Subject: Re: freeing memzone Date: Fri, 22 May 2015 09:30:55 +0100 Message-ID: <555EE93F.3080508@intel.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" To: Harish Patil Return-path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 9988A592B for ; Fri, 22 May 2015 10:30:58 +0200 (CEST) In-Reply-To: List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 21/05/2015 17:59, Harish Patil wrote: > Hello dpdk-dev, > > I understand that the reserved memzones cannot be freed, as mentioned i= n > the DPDK specs. But I would like to know why? Is there any limitations? There should be a few threads in the mailing list related to this topic. Last that comes to mind: http://dpdk.org/ml/archives/dev/2015-April/016501.html Short answer is, it has not been implemented yet. > If the memory is not freed/returned, then can it be reused for subseque= nt > allocations without re-init (i.e. with same memzone name)? > We use it for allocating DMA=E2=80=99ble memory. It is up to the application to manage the use/re-use of memzones. By the way, would maybe rte_malloc memory be more suitable than memzones=20 for your application? You can retrieve the physical address of memory allcoated by rte_malloc=20 with rte_malloc_virt2phy. > Secondly, there was a related discussion on this in the following email > thread: > http://dpdk.org/ml/archives/dev/2014-July/004456.html > > Do we plan to incorporate that changes? There is some ongoing work related to freeing memzones: http://dpdk.org/ml/archives/dev/2015-May/017470.html Feel free to comment on it. Sergio > Thanks, > Harish > > > ________________________________ > > This message and any attached documents contain information from the se= nding company or its parent company(s), subsidiaries, divisions or branch= offices that may be confidential. If you are not the intended recipient,= you may not read, copy, distribute, or use this information. If you have= received this transmission in error, please notify the sender immediatel= y by reply e-mail and then delete this message.