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 7B298A0528; Sat, 11 Jul 2020 09:52:08 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C748B1D9D5; Sat, 11 Jul 2020 09:52:07 +0200 (CEST) Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) by dpdk.org (Postfix) with ESMTP id 190E31D9D1 for ; Sat, 11 Jul 2020 09:52:07 +0200 (CEST) Received: by mail-wr1-f48.google.com with SMTP id z15so8013134wrl.8 for ; Sat, 11 Jul 2020 00:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=O9d1fLyXLuEtOMwIAo9es6pgfa9lhQmegrk5hJj2ioU=; b=Q9sA2imoISLz5Zj+JgdyJB6UQCAFUjvcxxqxhDJ5x7Wb6AzN5yaedkniUYV4uJpVzg IuXsBjTCrPO3b9ZzcXA6pBfuCtZKxZvukCDdlFZ3TUVvREfSKYsHoxW/p0dMn+YyWRA4 xSgyUAvTJ6UGn2+TrN418iOT3JjecbOZAP/o7/rumlVjmzAS0ZZzbBYPoXQKW78fihPE 7Qu1kxuTMTOjCeT5ju0CgsSK1X2eaP1vb9g2q8L6j1bcIh1zKa1GIsuMMj1TxvBbtdha nQzc8LxxmcGIquoaWQ60WajlzNYIRIqKkXfZRYc7kTfYZpAeERxZaVh538y0d9w1jerk OWig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=O9d1fLyXLuEtOMwIAo9es6pgfa9lhQmegrk5hJj2ioU=; b=oeHb4Qk8OEoIcMWrLjIPK4AIgrCCLSIwtgxX9BywICPxZiN2mT7eNy+jkIf6N8Z7BS TdM95NfM/YlmMORovAMhxonQrAfrcFDpy/Gop/dnwFaj+Jwl1KXh3n9a3ODTfdnrjCjQ 5iCTrIKUoH4TmB+cprY5rIS/vRn9LPPF0rYvPBUlos8GrNFg6tB5Y9grsRhR7/xDfkan dydHevJUpVLZVIAZHUAsFmqcbnxXQ5muXbM+8qs7I65Mm8Q/ScO6EhmIPEdP+mg+AqQg +PROBX0BjpwNB4hzmmAHNj66JJXZhGb8vv5pTlIEuhhEIZkfgIZ8J/fEfxHc/0NlVcXQ L3mg== X-Gm-Message-State: AOAM53304Yv4Hm2M0IPE82KdCbykWNiy8mOnXbKhqQDpQlTLH8T77j2v ACMyRgMpthScmllPOt7amKNHLM95Znx/A4/6MIs= X-Google-Smtp-Source: ABdhPJw+ppSZVtM/OpbmsUbfULh8i4hMQ8UMrdFuVZHSHB79CTPPnMMmWfJQt0sDHBBfMGsKjawKnR2kdP2Zmw+8nXU= X-Received: by 2002:adf:f60a:: with SMTP id t10mr64847435wrp.64.1594453926615; Sat, 11 Jul 2020 00:52:06 -0700 (PDT) MIME-Version: 1.0 References: <20200710102837.GB684@bricha3-MOBL.ger.corp.intel.com> In-Reply-To: From: Kamaraj P Date: Sat, 11 Jul 2020 13:21:55 +0530 Message-ID: To: "Burakov, Anatoly" Cc: Bruce Richardson , dev@dpdk.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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" Hello Anatoly/Bruce, We are using the 18_11 version of DPDK and we are using igb_uio. The way we observe an issue here is that, after we tried multiple iterations of start/stop of container application(which has DPDK), we were not able to allocate the memory for port during the init. We thought that it could be an issue of not getting continuous allocation hence it fails. Is there an API where I can check if the memory is fragmented before we invoke an allocation ? Or do we have any such mechanism to defragment the memory allocation once we exist from the application ? Please advise. Thanks, Kamaraj On Fri, Jul 10, 2020 at 9:14 PM Burakov, Anatoly wrote: > 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 >