DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Medvedkin, Vladimir" <vladimir.medvedkin@intel.com>
To: Andre Muezerie <andremue@linux.microsoft.com>,
	Stephen Hemminger <stephen@networkplumber.org>
Cc: <dev@dpdk.org>
Subject: Re: [PATCH] app/test: fix stack overflow in fib6_perf_autotest
Date: Tue, 24 Dec 2024 11:06:04 +0000	[thread overview]
Message-ID: <e5c179c6-c776-4477-8deb-f328e22ce327@intel.com> (raw)
In-Reply-To: <20241224014733.GA19006@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>

Hi,

I think using rte_malloc(rte_calloc) here would be a better choice because:

- As Andre mentioned allocation happens outside of the performance 
measurement section

- Due to relatively large size of the memory allocated for 
ip_batch/next_hops some CPUs may experience TLB cache pressure, which 
will affect performance measurement results.

With that being said

Acked-by: Vladimir Medvedkin <vladimir.medvedkin@intel.com>

On 24/12/2024 01:47, Andre Muezerie wrote:
> 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

-- 
Regards,
Vladimir


      reply	other threads:[~2024-12-24 11:06 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
2024-12-24 11:06     ` Medvedkin, Vladimir [this message]

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=e5c179c6-c776-4477-8deb-f328e22ce327@intel.com \
    --to=vladimir.medvedkin@intel.com \
    --cc=andremue@linux.microsoft.com \
    --cc=dev@dpdk.org \
    --cc=stephen@networkplumber.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).