From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) by dpdk.org (Postfix) with ESMTP id F35E812A1 for ; Wed, 7 May 2014 13:39:04 +0200 (CEST) Received: by mail-we0-f169.google.com with SMTP id u56so859942wes.14 for ; Wed, 07 May 2014 04:39:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=mLuzuHK7lOFl5N7Q17NhcmWge+WrfICm5UCimWR9xAI=; b=TeIZUu4eSIChlBJJToZNURHJmf1GBs0owp38ZS3+ELq+5pT22pfniLyo7IJK12VsPA 3ywq8BE0gtfchn8DgGRkkNEY4fH2djdRVK/rIESv89FgwFsVzPdkBrbrTHa/RRfZD5Ct tRkT9uD0iGGrTSUTAHhc9bXFpnFywGdOcf61hhiqEj4N061Ah8O6cIsD59VzxmpwDiT0 UQMcmH06RfRciNcyXEmBByKIOEb+5GOvJ0PkzfvyTHgZuj8sE/hCxdq9hh9QWz68AnVL dKY7O34aBCy2lM/iS0vkNDKQ5zhx5pAefJVIgtFIHgUnF72QKlxVa8tmLbDooBDKjfJG 3RPg== X-Gm-Message-State: ALoCoQmOLWnSa4Mfne1E9AugkemTdtMExBK31Hhrncju2t/cYy8Dkjk/xK/xnQxsr2YO5SEk75lk X-Received: by 10.194.71.164 with SMTP id w4mr38377557wju.0.1399462750836; Wed, 07 May 2014 04:39:10 -0700 (PDT) Received: from [10.16.0.195] (6wind.net2.nerim.net. [213.41.180.237]) by mx.google.com with ESMTPSA id km6sm26271003wjc.6.2014.05.07.04.39.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 May 2014 04:39:10 -0700 (PDT) Message-ID: <536A1B5C.2010201@6wind.com> Date: Wed, 07 May 2014 13:39:08 +0200 From: Olivier MATZ User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.4.0 MIME-Version: 1.0 To: Igor Ryzhov , dev@dpdk.org References: <5368A5E0.8090903@arccn.ru> <5369E6AF.4040402@arccn.ru> In-Reply-To: <5369E6AF.4040402@arccn.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] RTE Ring removing X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 11:39:05 -0000 Hi Igor, On 05/07/2014 09:54 AM, Igor Ryzhov wrote: > I noticed that in Memzone realization there is a special global variable > "free_memseg" containing pointers on free memory segments. > An memzone reserve function just finst the best segment for allocation > from this "free_memseg" variable. > > So I think there is a possibility to unreserve already reserved memory > back to "free_memseg", and impossibility of unreserving memory is just > because there is no function for that, not because it is impossible in > principle. > Am I right? Or there are any restrictions? I think that implementing a freeing of memory segment is feasible, but it would require some work to properly merge freed zones to avoid memory fragmentation. Another solution is to allocate/free rings in standard memory (malloc for instance) instead of rte_memzones. Let me know if the patches I've just sent on the mailing list solves your issue. By the way, I plan to do the same thing for mempools in the coming weeks but there is much more work. Regards, Olivier