From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 622F6A052A; Fri, 10 Jul 2020 17:44:25 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 31EF21DAAE; Fri, 10 Jul 2020 17:44:24 +0200 (CEST) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 623981DAAB for ; Fri, 10 Jul 2020 17:44:22 +0200 (CEST) IronPort-SDR: JHRh0K4Au3NwVpbls0/JHBDk7Dqbg+WIqlP1a2m60eMn/pYJMs7neOqh4nGg5PPyzvtPe2jFzS yl0HX2pJ0vGA== X-IronPort-AV: E=McAfee;i="6000,8403,9678"; a="128291518" X-IronPort-AV: E=Sophos;i="5.75,336,1589266800"; d="scan'208";a="128291518" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jul 2020 08:44:21 -0700 IronPort-SDR: DVs51AbDoVlIF5LpLc4Pd3Ts0qxWzRCDlsjnsmuJ1Nnr//u6JR1uFYz3e/VjeAiFU+aD0sWZpd kwpMc03DF6EA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,336,1589266800"; d="scan'208";a="284540817" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.213.1.123]) ([10.213.1.123]) by orsmga006.jf.intel.com with ESMTP; 10 Jul 2020 08:44:20 -0700 To: Bruce Richardson , Kamaraj P Cc: dev@dpdk.org References: <20200710102837.GB684@bricha3-MOBL.ger.corp.intel.com> From: "Burakov, Anatoly" Message-ID: Date: Fri, 10 Jul 2020 16:44:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <20200710102837.GB684@bricha3-MOBL.ger.corp.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] DPDK hugepage memory fragmentation 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 10-Jul-20 11:28 AM, Bruce Richardson wrote: > On Fri, Jul 10, 2020 at 02:52:16PM +0530, Kamaraj P wrote: >> Hello All, >> >> We are running to run DPDK based application in a container mode, >> When we do multiple start/stop of our container application, the DPDK >> initialization seems to be failing. >> This is because the hugepage memory fragementated and is not able to find >> the continuous allocation of the memory to initialize the buffer in the >> dpdk init. >> >> As part of the cleanup of the container, we do call rte_eal_cleanup() to >> cleanup the memory w.r.t our application. However after iterations we still >> see the memory allocation failure due to the fragmentation issue. >> >> We also tried to set the "--huge-unlink" as an argument before when we >> called the rte_eal_init() and it did not help. >> >> Could you please suggest if there is an option or any existing patches >> available to clean up the memory to avoid fragmentation issues in the >> future. >> >> Please advise. >> > What version of DPDK are you using, and what kernel driver for NIC > interfacing are you using? > DPDK versions since 18.05 should be more forgiving of fragmented memory, > especially if using the vfio-pci kernel driver. > This sounds odd, to be honest. Unless you're allocating huge chunks of IOVA-contiguous memory, fragmentation shouldn't be an issue. How did you determine that this was in fact due to fragmentation? > Regards, > /Bruce > -- Thanks, Anatoly