DPDK patches and discussions
 help / color / mirror / Atom feed
From: Andre Muezerie <andremue@linux.microsoft.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: Vladimir Medvedkin <vladimir.medvedkin@intel.com>, dev@dpdk.org
Subject: Re: [PATCH] app/test: fix stack overflow in fib6_perf_autotest
Date: Mon, 23 Dec 2024 17:47:33 -0800	[thread overview]
Message-ID: <20241224014733.GA19006@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> (raw)
In-Reply-To: <20241223133000.0a761f5a@fedora>

On Mon, Dec 23, 2024 at 01:30:00PM -0800, Stephen Hemminger wrote:
> On Mon, 23 Dec 2024 13:10:33 -0800
> Andre Muezerie <andremue@linux.microsoft.com> wrote:
> 
> > From: Andre Muezerie <andremue@linux.microsoft.com>
> > To: Vladimir Medvedkin <vladimir.medvedkin@intel.com>
> > Cc: dev@dpdk.org,  Andre Muezerie <andremue@linux.microsoft.com>
> > Subject: [PATCH] app/test: fix stack overflow in fib6_perf_autotest
> > Date: Mon, 23 Dec 2024 13:10:33 -0800
> > X-Mailer: git-send-email 1.8.3.1
> > 
> > Test fib6_perf_autotest was hitting a stack overflow on Windows
> > with MSVC.
> > 
> > The fix is to move some of the data from the stack to the heap.
> > 
> > Signed-off-by: Andre Muezerie <andremue@linux.microsoft.com>
> 
> Use regular malloc please.
> rte_malloc comes from hugepages which are more limited and slower to manipulate.

I recently submitted a patch for a test with a very similar issue and
during review one of the reviewers encouraged me to use rte_calloc to
allocate memory for the arrays, which I think makes sense (I had used
malloc initially):

https://inbox.dpdk.org/dev/20241218151206.GA25758@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net/

Even though this is a perf test, the code responsible for the memory
allocations is not in the path for which time measurements are being
taken (points between rte_rdtsc calls), so perf for the memory
allocation code is probably not so critical.

That being said, if you still feel strongly that malloc should be used
instead let me know and I can make that change.

Thanks,

Andre Muezerie

  reply	other threads:[~2024-12-24  1:47 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-23 21:10 Andre Muezerie
2024-12-23 21:30 ` Stephen Hemminger
2024-12-24  1:47   ` Andre Muezerie [this message]
2024-12-24 11:06     ` Medvedkin, Vladimir

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=20241224014733.GA19006@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net \
    --to=andremue@linux.microsoft.com \
    --cc=dev@dpdk.org \
    --cc=stephen@networkplumber.org \
    --cc=vladimir.medvedkin@intel.com \
    /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).