DPDK patches and discussions
 help / color / mirror / Atom feed
From: Gopakumar Choorakkot Edakkunni <gopakumar.c.e@gmail.com>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] Using rte_ring_mp_xyz() across EAL and non-EAL threads ?
Date: Fri, 3 Jul 2015 20:13:47 -0700	[thread overview]
Message-ID: <CABK1yFB305Z-bGLySu5h9LFToEmd3eNs5BNZXkG2hFv9o7V92w@mail.gmail.com> (raw)
In-Reply-To: <20150702092040.GA7688@bricha3-MOBL3>

Thanks for the clarification Bruce. But I find this link below in the
documentation which says it should not be used in cases where the
scheduling policy is SCHED_RR because guess it can lead to an endless
spin-lock-wait by the SCHED_RR thread waiting for the lower prio
thread which got pre-empted. I am assuming this is a very unlikely
situation 32 core Xeon like cpu where a low prio thread never gets
scheduled because there are always realtime threads with work to do ?
But since the warning is in bold and pretty loud :), I decided not to
use that and just do a handoff with a standard mutex-lock :(. If my
threads were not realtime (not SCHED_RR), I could have used this!

http://dpdk.org/doc/guides/prog_guide/env_abstraction_layer.html section 3.3.4.

"The “non-preemptive” constraint means: Bypassing this constraint it
may cause the 2nd pthread to spin until the 1st one is scheduled
again. Moreover, if the 1st pthread is preempted by a context that has
an higher priority, it may even cause a dead lock."


Rgds,
Gopa.

On Thu, Jul 2, 2015 at 2:20 AM, Bruce Richardson
<bruce.richardson@intel.com> wrote:
> On Wed, Jul 01, 2015 at 10:50:49AM -0700, Gopakumar Choorakkot Edakkunni wrote:
>> rte_ring_create() needs a socket-id though and seems to be allocating
>> core-specific memory pools for the ring ? But my non-EAL app thread is
>> not bound to any core, so now I am wondering if that will work.
>>
>> Rgds,
>> Gopa.
>
> There are no core-specific elements for rte_rings, just for mempools. Yes, you
> need a NUMA node ID when creating the ring, so that DPDK knows where to allocate
> the memory for it. However, once that is done, the ring can safely be used from
> both EAL and non-EAL threads. There is no requirement to have an lcore-id for
> the thread.
>
> /Bruce
>
>>
>> On Wed, Jul 1, 2015 at 10:46 AM, Gopakumar Choorakkot Edakkunni
>> <gopakumar.c.e@gmail.com> wrote:
>> > Hi,
>> >
>> > I have a requirement where one of my non-EAL app threads needs to
>> > handoff some packets to an EAL task. I was thinking of using
>> > rte_ring_mp_enqueue/dequeue for that purpose. I looked at the code for
>> > the rte_ring library and it doesnt look like it has any "EAL"
>> > dependencies, but I wanted to double confirm that there are no issues
>> > in using it that way. Dint find much yes/no info about that on the
>> > mailers/docs. Pls let me know your thoughts.
>> >
>> > Rgds,
>> > Gopa.

  reply	other threads:[~2015-07-04  3:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-01 17:46 Gopakumar Choorakkot Edakkunni
2015-07-01 17:50 ` Gopakumar Choorakkot Edakkunni
2015-07-02  9:20   ` Bruce Richardson
2015-07-04  3:13     ` Gopakumar Choorakkot Edakkunni [this message]
2015-07-06  9:12       ` 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=CABK1yFB305Z-bGLySu5h9LFToEmd3eNs5BNZXkG2hFv9o7V92w@mail.gmail.com \
    --to=gopakumar.c.e@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).