DPDK patches and discussions
 help / color / mirror / Atom feed
From: Kamaraj P <pkamaraj@gmail.com>
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Cc: Bruce Richardson <bruce.richardson@intel.com>, dev@dpdk.org
Subject: Re: [dpdk-dev] DPDK hugepage memory fragmentation
Date: Sat, 11 Jul 2020 13:21:55 +0530	[thread overview]
Message-ID: <CAG8PAaqy4UBDnO9uJGmON=n1s-D69ujzt6v2HatFw9DixpL2HQ@mail.gmail.com> (raw)
In-Reply-To: <d9d25343-e6ce-e77f-6c29-bf31ace74942@intel.com>

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 <anatoly.burakov@intel.com>
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
>

  reply	other threads:[~2020-07-11  7:52 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-10  9:22 Kamaraj P
2020-07-10 10:28 ` Bruce Richardson
2020-07-10 15:44   ` Burakov, Anatoly
2020-07-11  7:51     ` Kamaraj P [this message]
2020-07-13  9:27       ` Burakov, Anatoly
2020-07-27 15:30         ` Kamaraj P
2020-07-28 10:10           ` Burakov, Anatoly
2020-09-16  4:32             ` Kamaraj P
2020-09-16 11:19               ` Burakov, Anatoly
2020-09-16 11:47                 ` Burakov, Anatoly

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAG8PAaqy4UBDnO9uJGmON=n1s-D69ujzt6v2HatFw9DixpL2HQ@mail.gmail.com' \
    --to=pkamaraj@gmail.com \
    --cc=anatoly.burakov@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).