DPDK patches and discussions
 help / color / mirror / Atom feed
From: David Marchand <david.marchand@redhat.com>
To: "Yigit, Ferruh" <ferruh.yigit@linux.intel.com>
Cc: dev <dev@dpdk.org>, Aaron Conole <aconole@redhat.com>
Subject: Re: [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE
Date: Mon, 20 Jan 2020 20:35:25 +0100	[thread overview]
Message-ID: <CAJFAV8xO0911BYzeoYVhNhM6o4TSOrRG4iM9LZqVEc9d46Ruzg@mail.gmail.com> (raw)
In-Reply-To: <a2666936-c16e-8ede-7cbf-f430627472fc@linux.intel.com>

On Mon, Jan 20, 2020 at 7:37 PM Yigit, Ferruh
<ferruh.yigit@linux.intel.com> wrote:
>
> On 12/2/2019 3:35 PM, David Marchand wrote:
> > We are currently stuck with no option but recompile a DPDK if the system
> > has more cores than RTE_MAX_LCORE.
> > A bit of a pity when you get a system with more than 200+ cores and your
> > testpmd has been built and packaged with RTE_MAX_LCORE == 128.
>
> Just for clarification, in this case the DPDK application will work but will
> only use RTE_MAX_LCORE cores, right? You need to compile to use all available cores.

EAL starts up to RTE_MAX_LCORE lcores (as in EAL threads), that's true
before and after this patch.

By default (using the -c or -l options), a lcore X runs on the physical core X.
With the --lcores option, you can select on which physical cores a lcore runs.

But, before this series, the code limits the physical cores to the
same [0, RTE_MAX_LCORE[ range.

>
> Are cores more than RTE_MAX_LCORE usable after this patch?

Yes, see below.


>
> >
> > The --lcores does not need to care about the underlying cores, remove
> > this limitation.
> >
>
> +1 to remove limit in --lcores, but I didn't make it work with this patchset, I
> may be missing something, I tried by setting the "RTE_MAX_LCORE=32", in this
> case should '--lcores "(30-40)@(10-20)"' work?

Quoting the parser code:
 * The format pattern: --lcores='<lcores[@cpus]>[<,lcores[@cpus]>...]'
 * lcores, cpus could be a single digit/range or a group.
 * '(' and ')' are necessary if it's a group.
 * If not supply '@cpus', the value of cpus uses the same as lcores.
 * e.g. '1,2@(5-7),(3-5)@(0,2),(0,6),7-8' means start 9 EAL thread as below
 *   lcore 0 runs on cpuset 0x41 (cpu 0,6)
 *   lcore 1 runs on cpuset 0x2 (cpu 1)
 *   lcore 2 runs on cpuset 0xe0 (cpu 5,6,7)
 *   lcore 3,4,5 runs on cpuset 0x5 (cpu 0,2)
 *   lcore 6 runs on cpuset 0x41 (cpu 0,6)
 *   lcore 7 runs on cpuset 0x80 (cpu 7)
 *   lcore 8 runs on cpuset 0x100 (cpu 8)

With --lcores "(30-40)@(10-20)", you asked to start lcores 30 to 40 to
run on the cpuset 10 to 20.
So it will be refused, since the max lcore is 32.

If your intention was to start lcore 10 on physical core 30, lcore 11
on core 31 etc... then you can try --lcores 10@30,11@31,12@32...


-- 
David Marchand


  reply	other threads:[~2020-01-20 19:35 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-02 15:35 David Marchand
2019-12-02 15:41 ` [dpdk-dev] [PATCH 1/4] eal/windows: fix cpuset macro name David Marchand
2019-12-02 15:42 ` [dpdk-dev] [PATCH 2/4] eal: do not cache lcore detection state David Marchand
2019-12-02 15:42 ` [dpdk-dev] [PATCH 3/4] eal: display all detected cores at startup David Marchand
2019-12-02 15:42 ` [dpdk-dev] [PATCH 4/4] eal: remove limitation on cpuset with --lcores David Marchand
2020-01-14 12:58 ` [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE David Marchand
2020-01-14 15:32   ` [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores >RTE_MAX_LCORE Morten Brørup
2020-01-20 18:37 ` [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE Yigit, Ferruh
2020-01-20 19:35   ` David Marchand [this message]
2020-01-21  0:24 ` Thomas Monjalon
2020-02-21  8:04   ` Thomas Monjalon
2020-02-21  8:19     ` Song, Keesang
2020-02-21  9:40       ` David Marchand
2020-02-21 14:48         ` Aaron Conole
2020-02-21 16:38           ` Stephen Hemminger
2020-05-29  3:05     ` Song, Keesang
2020-05-29  3:05       ` Song, Keesang
2020-06-01 21:22         ` Thomas Monjalon
2020-06-01 22:54           ` Song, Keesang
2020-06-09 16:30             ` Song, Keesang
2020-06-09 17:48               ` Luca Boccassi
2020-06-09 21:34                 ` Kevin Traynor

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=CAJFAV8xO0911BYzeoYVhNhM6o4TSOrRG4iM9LZqVEc9d46Ruzg@mail.gmail.com \
    --to=david.marchand@redhat.com \
    --cc=aconole@redhat.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@linux.intel.com \
    /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).