DPDK patches and discussions
 help / color / mirror / Atom feed
From: Olivier Matz <olivier.matz@6wind.com>
To: Matteo Lanzuisi <m.lanzuisi@resi.it>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] Multi-thread mempool usage
Date: Mon, 13 Aug 2018 23:54:24 +0200	[thread overview]
Message-ID: <20180813215424.cesdejskukrrt4zf@neon> (raw)
In-Reply-To: <a4f1fa01-c838-671d-9f52-5e790a5007a4@resi.it>

Hello Matteo,

On Mon, Aug 13, 2018 at 03:20:44PM +0200, Matteo Lanzuisi wrote:
> Any suggestion? any idea about this behaviour?
> 
> Il 08/08/2018 11:56, Matteo Lanzuisi ha scritto:
> > Hi all,
> > 
> > recently I began using "dpdk-17.11-11.el7.x86_64" rpm (RedHat rpm) on
> > RedHat 7.5 kernel 3.10.0-862.6.3.el7.x86_64 as a porting of an
> > application from RH6 to RH7. On RH6 I used dpdk-2.2.0.
> > 
> > This application is made up by one or more threads (each one on a
> > different logical core) reading packets from i40e interfaces.
> > 
> > Each thread can call the following code lines when receiving a specific
> > packet:
> > 
> > RTE_LCORE_FOREACH(lcore_id)
> > {
> >         result =
> > rte_mempool_get(cea_main_lcore_conf[lcore_id].de_conf.cmd_pool, (VOID_P
> > *) &new_work);        // mempools are created one for each logical core
> >         if (((uint64_t)(new_work)) < 0x7f0000000000)
> >             printf("Result %d, lcore di partenza %u, lcore di ricezione
> > %u, pointer %p\n", result, rte_lcore_id(), lcore_id, new_work);    //
> > debug print, on my server it should never happen but with multi-thread
> > happens always on the last logical core!!!!

Here, checking the value of new_work looks wrong to me, before
ensuring that result == 0. At least, new_work should be set to
NULL before calling rte_mempool_get().

> >         if (result == 0)
> >         {
> >             new_work->command = command; // usage of the memory gotten
> > from the mempool... <<<<<- here is where the application crashes!!!!

Do you know why it crashes? Is it that new_work is NULL?

Can you check how the mempool is initialized? It should be in multi
consumer and depending on your use case, single or multi producer.

Another thing that could be checked: at all the places where you
return your work object to the mempool, you should add a check
that it is not NULL. Or just enabling RTE_LIBRTE_MEMPOOL_DEBUG
could do the trick: it adds some additional checks when doing
mempool operations.

> >             result =
> > rte_ring_enqueue(cea_main_lcore_conf[lcore_id].de_conf.cmd_ring,
> > (VOID_P) new_work);    // enqueues the gotten buffer on the rings of all
> > lcores
> >             // check on result value ...
> >         }
> >         else
> >         {
> >             // do something if result != 0 ...
> >         }
> > }
> > 
> > This code worked perfectly (never had an issue) on dpdk-2.2.0, while if
> > I use more than 1 thread doing these operations on dpdk-17.11 it happens
> > that after some times the "new_work" pointer is not a good one, and the
> > application crashes when using that pointer.
> > 
> > It seems that these lines cannot be used by more than one thread
> > simultaneously. I also used many 2017 and 2018 dpdk versions without
> > success.
> > 
> > Is this code possible on the new dpdk versions? Or have I to change my
> > application so that this code is called just by one lcore at a time?

Assuming the mempool is properly initialized, I don't see any reason
why it would not work. There has been a lot of changes in mempool between
dpdk-2.2.0 and dpdk-17.11, but this behavior should remain the same.

If the comments above do not help to solve the issue, it could be helpful
to try to reproduce the issue in a minimal program, so we can help to
review it.

Regards,
Olivier

  reply	other threads:[~2018-08-13 21:54 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-08  9:56 Matteo Lanzuisi
2018-08-13 13:20 ` Matteo Lanzuisi
2018-08-13 21:54   ` Olivier Matz [this message]
2018-08-20 14:47     ` Matteo Lanzuisi
2018-08-20 16:03       ` Wiles, Keith
2018-08-21 12:01         ` Matteo Lanzuisi
2018-08-21 12:17           ` Wiles, Keith
2018-08-21 12:44             ` Matteo Lanzuisi
2018-08-21 12:51               ` Wiles, Keith
2018-08-21 14:46                 ` Matteo Lanzuisi
2018-08-24 14:44                   ` Matteo Lanzuisi
2018-08-24 16:47                     ` Wiles, Keith
2018-08-27 15:34                       ` Matteo Lanzuisi

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=20180813215424.cesdejskukrrt4zf@neon \
    --to=olivier.matz@6wind.com \
    --cc=dev@dpdk.org \
    --cc=m.lanzuisi@resi.it \
    /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).