DPDK patches and discussions
 help / color / mirror / Atom feed
From: Prashant Upadhyaya <praupadhyaya@gmail.com>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: dev@dpdk.org
Subject: Re: Regarding DPDK API's like rte_timer_subsystem_init/rte_hash_create etc. in VPP
Date: Thu, 30 Mar 2023 18:42:58 +0530	[thread overview]
Message-ID: <CAPBAu3X6PkxAEH4pxQ6_1=wfjg_zXfE+rdNi2mrX6GPLQNcn2A@mail.gmail.com> (raw)
In-Reply-To: <ZCVUaHj09kAjjMwY@bricha3-MOBL.ger.corp.intel.com>

On Thu, Mar 30, 2023 at 2:50 PM Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> On Thu, Mar 30, 2023 at 01:57:52PM +0530, Prashant Upadhyaya wrote:
> > Hi,
> >
>
> FYI, when replying on list, it's best not to top-post, but put your replies
> below the email snippet you are replying to.
>
> > The hash creation API throws the following error --
> > RING: Cannot reserve memory for tailq
> > HASH: memory allocation failed
> >
> > The timer subsystem init api throws this error --
> > EAL: memzone_reserve_aligned_thread_unsafe(): Number of requested
> > memzone segments exceeds RTE_MAX_MEMZONE
> >
>
> Can you try increasing RTE_MAX_MEMZONE. It' defined in DPDK's rte_config.h
> file, so edit that and then rebuild DPDK. [If you are using the built-in
> DPDK from VPP, you may need to do a patch for this, add it into the VPP
> patches direction and then do a VPP rebuild.]
>
> Let's see if we can get rid of at least one of the error messages. :-)
>
> /Bruce
>
> > I did check the code and apparently the memzone and rte zmalloc
> > related api's are not being able to allocate memory.
> >
> > Regards
> > -Prashant
> >
> > On Thu, Mar 30, 2023 at 1:30 PM Bruce Richardson
> > <bruce.richardson@intel.com> wrote:
> > >
> > > On Thu, Mar 30, 2023 at 10:30:24AM +0530, Prashant Upadhyaya wrote:
> > > > Hi,
> > > >
> > > > While trying to port some code to VPP (which uses DPDK as the backend
> > > > driver), I am running into a problem that calls to API's like
> > > > rte_timer_subsystem_init, rte_hash_create are failing while allocation
> > > > of memory.
> > > >
> > > > This is presumably because VPP inits the EAL with the following arguments --
> > > >
> > > > -in-memory --no-telemetry --file-prefix vpp
> > > >
> > > > Is  there is something that can be done eg. passing some more parms in
> > > > the EAL initialization which hopefully wouldn't break VPP but will
> > > > also be friendly to the RTE timer and hash functions too, that would
> > > > be great, so requesting some advice here.
> > > >
> > > Hi,
> > >
> > > can you provide some more details on what the errors are that you are
> > > receiving? Have you been able to dig a little deeper into what might be
> > > causing the memory failures? The above flags alone are unlikely to cause
> > > issues with hash or timer libraries, for example.
> > >
> > > /Bruce

Thanks Bruce, the error comes from the following function in
lib/eal/common/eal_common_memzone.c
memzone_reserve_aligned_thread_unsafe

The condition which spits out the error is the following
if (arr->count >= arr->len)
So I printed both of the above values inside this function, and the
following output came

vpp[14728]: dpdk: EAL init args: --in-memory --no-telemetry --file-prefix vpp
[New Thread 0x7fffa67b6700 (LWP 14732)]
count: 0 len: 2560
count: 1 len: 2560
count: 2 len: 2560
[New Thread 0x7fffa5fb5700 (LWP 14733)]
[New Thread 0x7fffa5db4700 (LWP 14734)]
count: 3 len: 2560
count: 4 len: 2560
### this is the place where I call rte_timer_subsystem_init from my
code, the above must be coming from any other code from VPP/EAL init,
the line below is surely because of my call to
rte_timer_subsystem_init
count: 0 len: 0

So as you can see that both values are coming to be zero -- is this
expected ? I thought the arr->len should have been non zero.
I must add that the thread which is calling the
rte_timer_subsystem_init is possibly different than the one which did
the eal init, do you think that might be a problem...
I am yet to increase the value of RTE_MAX_MEMZONE, but wanted to share
the above first for any suggestions.

Regards
-Prashant

  reply	other threads:[~2023-03-30 13:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-30  5:00 Prashant Upadhyaya
2023-03-30  8:00 ` Bruce Richardson
2023-03-30  8:27   ` Prashant Upadhyaya
2023-03-30  9:20     ` Bruce Richardson
2023-03-30 13:12       ` Prashant Upadhyaya [this message]
2023-03-30 13:17         ` Bruce Richardson
2023-03-30 13:37           ` Prashant Upadhyaya
2023-03-30 14:02             ` Bruce Richardson
2023-03-31  9:41               ` Prashant Upadhyaya
2023-03-31 10:49                 ` Bruce Richardson
2023-04-14  4:25                   ` Prashant Upadhyaya
2023-04-14  9:07                     ` Bruce Richardson

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='CAPBAu3X6PkxAEH4pxQ6_1=wfjg_zXfE+rdNi2mrX6GPLQNcn2A@mail.gmail.com' \
    --to=praupadhyaya@gmail.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).