DPDK usage discussions
 help / color / mirror / Atom feed
From: Cliff Burdick <shaklee3@gmail.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: users <users@dpdk.org>
Subject: Re: [dpdk-users] Coremask
Date: Fri, 15 Apr 2016 14:57:56 -0700	[thread overview]
Message-ID: <CA+Gp1nYxQwA8N1Xq_ZiSLpjE+7Kr9yQv_1dFdc4JK8+bznnziw@mail.gmail.com> (raw)
In-Reply-To: <20160413111013.2d56cb28@xeon-e3>

Thanks Stephen. One of the issues I'm having is that it seems the master
lcore is the *only* one that can receive from one of the queues I created
on a port. For instance, I start my app with 5 cores, 0-4, where I want 1-4
to listen to port 0 , queue 0-3, and core 0 to be the master. I launch all
4 workers with rte_eal_remote_launch on cores 1-4, and the master (0) sits
there waiting on rte_eal_mp_wait_lcore(). However, I receive no packets on
core 1 even though it's listening to the proper queue. If I copy the code
that's listening on core 1 and stick it in the master lcore, it sees all
the packets. Is there some lcore->queue binding that I'm missing? I thought
that by launching with rte_eal_remote_launch on all but the master core
would work, but it doesn't.

My main goal is to have the master run on its own core not doing packet
processing, but periodically printing stats out. It's similar to the l2fwd
example, except in that example, the master is also processing packets.

On Wed, Apr 13, 2016 at 11:10 AM, Stephen Hemminger <
stephen@networkplumber.org> wrote:

> On Wed, 13 Apr 2016 09:42:29 -0700
> Cliff Burdick <shaklee3@gmail.com> wrote:
>
> > I don't see the answer to this in the documentation, so I'll try here.
> Why
> > function does the coremask that's required in rte_eal_init() actually do
> > other than tell the API what cores you're using? In other words, can't I
> > just set the core mask to all of the cores in my system, and selectively
> > use the ones I want? Is there a downside to that? What if the particular
> > thread running on an lcore isn't doing any DPDK functions?
>
> The coremask is used to determine which CPU's are setup and a per-cpu
> thread is started by the launch operation.
>
> You can tell EAL about as many CPU's as you want, either all or even
> just one. If you use all CPU's, then in the launch it is possible to
> have the thread function of unneeded CPU's return and go back to the
> launch idle loop.
>

      reply	other threads:[~2016-04-15 21:57 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-13 16:42 Cliff Burdick
2016-04-13 18:10 ` Stephen Hemminger
2016-04-15 21:57   ` Cliff Burdick [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=CA+Gp1nYxQwA8N1Xq_ZiSLpjE+7Kr9yQv_1dFdc4JK8+bznnziw@mail.gmail.com \
    --to=shaklee3@gmail.com \
    --cc=stephen@networkplumber.org \
    --cc=users@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).