DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Bruce Richardson" <bruce.richardson@intel.com>, <dev@dpdk.org>
Cc: <david.marchand@redhat.com>
Subject: RE: [PATCH v4 3/3] doc: provide examples of using lcores EAL parameter
Date: Wed, 14 May 2025 13:38:59 +0200	[thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35E9FC50@smartserver.smartshare.dk> (raw)
In-Reply-To: <20250513161710.410000-4-bruce.richardson@intel.com>

> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Tuesday, 13 May 2025 18.17
> 
> The "--lcores" EAL parameter has a very powerful syntax that can be
> used
> to provide precise control over lcore mappings. The docs however, only
> provided a minimal description of what it can do. Augment the docs by
> providing some examples of use of the option, and what the resulting
> core mappings would be.
> 
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
> ---
>  doc/guides/linux_gsg/eal_args.include.rst | 27 +++++++++++++++++++++++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/doc/guides/linux_gsg/eal_args.include.rst
> b/doc/guides/linux_gsg/eal_args.include.rst
> index 01fe6a3006..d530215784 100644
> --- a/doc/guides/linux_gsg/eal_args.include.rst
> +++ b/doc/guides/linux_gsg/eal_args.include.rst
> @@ -23,6 +23,33 @@ Lcore-related options
>      The grouping ``()`` can be omitted for single element group.
>      The ``@`` can be omitted if cpus and lcores have the same value.
> 
> +    Examples:
> +
> +    ``--lcores=1-3``: Run threads on physical CPUs 1, 2 and 3,
> +    with each thread having the same lcore id as the physical CPU id.
> +
> +    ``--lcores=1@(1,2)``: Run a single thread with lcore id 1,
> +    but with that thread bound to both physical CPUs 1 and 2,
> +    so it can run on either, as determined by the operating system.
> +
> +    ``--lcores='1@31,2@32,3@33'``: Run threads having internal lcore
> ids of 1, 2 and 3,
> +    but with the threads being bound to physical CPUs 31, 32 and 33
> respectively.
> +
> +    ``--lcores='(1-3)@(31-33)'``: Run three threads with lcore ids 1,
> 2 and 3.
> +    Unlike the previous example above,
> +    each of these threads is not bound to one specific physical CPU,
> +    but rather, all three threads are instead bound to the three
> physical CPUs 31, 32 and 33.
> +    This means that each of the three threads can move between the
> physical CPUs 31-33,
> +    as decided by the OS as the application runs.
> +
> +    ``--lcores=(1-3)@20``: Run three threads, with lcore ids 1, 2 and
> 3,
> +    where all three threads are bound to (can only run on) physical
> CPU 20.

Just noticed...

Some examples use: --lcores=XYZ
And some use: --lcores='XYZ'

Are the apostrophes required in some cases?
If not, please remove them.

> +
> +.. Note::
> +    Binding multiple DPDK lcores to a single physical CPU can cause
> problems with poor performance
> +    or deadlock when using DPDK rings or memory pools or spinlocks.
> +    Such a configuration should only be used with care.
> +
>  .. Note::
>      At a given instance only one core option ``--lcores``, ``-l`` or
> ``-c`` can
>      be used.
> --
> 2.45.2


  reply	other threads:[~2025-05-14 11:39 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-13 11:38 [RFC PATCH 0/3] allow easier use of high lcore-ids Bruce Richardson
2025-03-13 11:38 ` [RFC PATCH 1/3] eal: centralize core parameter parsing Bruce Richardson
2025-03-13 11:38 ` [RFC PATCH 2/3] eal: convert core masks and lists to core sets Bruce Richardson
2025-03-13 11:38 ` [RFC PATCH 3/3] eal: allow automatic mapping of high lcore ids Bruce Richardson
2025-03-24 17:30 ` [PATCH v2 0/3] allow easier use of high lcore-ids Bruce Richardson
2025-03-24 17:30   ` [PATCH v2 1/3] eal: centralize core parameter parsing Bruce Richardson
2025-04-07  6:58     ` David Marchand
2025-03-24 17:30   ` [PATCH v2 2/3] eal: convert core masks and lists to core sets Bruce Richardson
2025-04-07  6:59     ` David Marchand
2025-03-24 17:30   ` [PATCH v2 3/3] eal: allow automatic mapping of high lcore ids Bruce Richardson
2025-04-01 14:06   ` [PATCH v2 0/3] allow easier use of high lcore-ids Bruce Richardson
2025-04-07  7:04     ` David Marchand
2025-04-07  9:48       ` Bruce Richardson
2025-04-07 10:15         ` Morten Brørup
2025-04-07 10:40           ` Bruce Richardson
2025-04-07 11:32             ` Morten Brørup
2025-04-07 11:56               ` Bruce Richardson
2025-04-07 12:25                 ` Morten Brørup
2025-04-07 12:41                   ` Bruce Richardson
2025-04-07 13:18                     ` Morten Brørup
2025-04-07 13:24                       ` Bruce Richardson
2025-04-07 15:14           ` Stephen Hemminger
2025-04-07 15:38             ` Bruce Richardson
2025-05-02 15:11 ` [PATCH v3 0/4] rework and expand EAL lcore options Bruce Richardson
2025-05-02 15:11   ` [PATCH v3 1/4] eal: deprecate old coremask-based EAL parameters Bruce Richardson
2025-05-02 15:51     ` Stephen Hemminger
2025-05-02 16:00       ` Bruce Richardson
2025-05-03  6:09         ` Morten Brørup
2025-05-02 15:11   ` [PATCH v3 2/4] eal: merge corelist and core mapping options Bruce Richardson
2025-05-02 15:11   ` [PATCH v3 3/4] doc: provide examples of using lcores EAL parameter Bruce Richardson
2025-05-02 15:11   ` [PATCH v3 4/4] eal: add option for auto-mapping cpu ids to low lcore ids Bruce Richardson
2025-05-13 16:21     ` Bruce Richardson
2025-05-04 21:17   ` [PATCH v3 0/4] rework and expand EAL lcore options Patrick Robb
2025-05-13 16:17 ` [PATCH v4 0/3] lcore options cleanup Bruce Richardson
2025-05-13 16:17   ` [PATCH v4 1/3] eal: deprecate old coremask-based EAL parameters Bruce Richardson
2025-05-13 16:17   ` [PATCH v4 2/3] eal: merge corelist and core mapping options Bruce Richardson
2025-05-13 16:17   ` [PATCH v4 3/3] doc: provide examples of using lcores EAL parameter Bruce Richardson
2025-05-14 11:38     ` Morten Brørup [this message]
2025-05-14 12:14       ` 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=98CBD80474FA8B44BF855DF32C47DC35E9FC50@smartserver.smartshare.dk \
    --to=mb@smartsharesystems.com \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.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).