From: Thomas Monjalon <thomas@monjalon.net>
To: "Kevin Traynor" <ktraynor@redhat.com>,
"Tummala, Sivaprasad" <Sivaprasad.Tummala@amd.com>,
"David Marchand" <david.marchand@redhat.com>,
"Ferruh Yigit" <ferruh.yigit@amd.com>,
bruce.richardson@intel.com, konstantin.v.ananyev@yandex.ru,
"Morten Brørup" <mb@smartsharesystems.com>,
maxime.coquelin@redhat.com, "Aaron Conole" <aconole@redhat.com>
Cc: dev@dpdk.org
Subject: Re: [PATCH] config/x86: config support for AMD EPYC processors
Date: Mon, 06 Nov 2023 22:05:15 +0100 [thread overview]
Message-ID: <15039672.JCcGWNJJiE@thomas> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9EF51@smartserver.smartshare.dk>
17/10/2023 12:27, Morten Brørup:
> > >> From: Tummala, Sivaprasad <Sivaprasad.Tummala@amd.com>
> > >>> From: David Marchand <david.marchand@redhat.com>
> > >>> On Mon, Sep 25, 2023 at 5:11 PM Sivaprasad Tummala
> > >>>> From: Sivaprasad Tummala <Sivaprasad.Tummala@amd.com>
> > >>>>
> > >>>> By default, max lcores are limited to 128 for x86 platforms.
> > >>>> On AMD EPYC processors, this limit needs to be increased to
> > leverage
> > >>>> all the cores.
> > >>>>
> > >>>> The patch adjusts the limit specifically for native compilation on
> > >>>> AMD EPYC CPUs.
> > >>>>
> > >>>> Signed-off-by: Sivaprasad Tummala <Sivaprasad.Tummala@amd.com>
> > >>>
> > >>> This patch is a revamp of
> > >>>
> > >>
> > http://inbox.dpdk.org/dev/BY5PR12MB3681C3FC6676BC03F0B42CCC96789@BY5PR
> > >>> 12MB3681.namprd12.prod.outlook.com/
> > >>> for which a discussion at techboard is supposed to have taken place.
> > >>> But I didn't find a trace of it.
> > >>>
> > >>> One option that had been discussed in the previous thread was to
> > >>> increase the max number of cores for x86.
> > >>> I am unclear if this option has been properly evaluated/debatted.
>
> Here are the minutes from the previous techboard discussions:
> [1]: http://inbox.dpdk.org/dev/YZ43U36bFWHYClAi@platinum/
> [2]: http://inbox.dpdk.org/dev/20211202112506.68acaa1a@hermes.local/
>
> AFAIK, there has been no progress with dynamic max_lcores, so I guess the techboard's conclusion still stands:
>
> There is no identified use-case where a single application requires more than 128 lcores. If a case a use-case exists for a single application that uses more than 128 lcores, the TB is ok to update the default config value.
>
> > >>>
> > >>> Can the topic be brought again at techboard?
> > >>
> > >> Hi David,
> > >>
> > >> The patch is intended to detect AMD platforms and enable all CPU
> > cores by default
> > >> on native builds.
>
> This is done on native ARM builds, so why not on native X86 builds too?
>
> > >>
> > >> As an optimization for memory footprint, users can override this by
> > specifying "-
> > >> Dmax_lcores" option based on DPDK lcores required for their usecases.
> > >>
> > >> Sure, will request to add this topic for discussion at techboard.
This is the summary of the techboard meeting:
(see https://mails.dpdk.org/archives/dev/2023-October/279672.html)
- There is some asks for more than 128 worker cores
- Discussion about generally increasing the default max core count and
trade-offs with memory consumption but this is longer term issue
- Acceptance for the direction of this patch in the short term
- Details of whether it should be for EPYC only or x86 to be figured out
on mailing list
So now let's figure out the details please.
Suggestions?
next prev parent reply other threads:[~2023-11-06 21:05 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-25 15:10 Sivaprasad Tummala
2023-10-06 7:50 ` David Marchand
2023-10-16 5:14 ` Tummala, Sivaprasad
2023-10-16 5:20 ` Tummala, Sivaprasad
2023-10-17 9:45 ` Kevin Traynor
2023-10-17 10:27 ` Morten Brørup
2023-11-06 21:05 ` Thomas Monjalon [this message]
2023-11-06 22:17 ` Morten Brørup
2023-11-07 13:13 ` Konstantin Ananyev
2023-11-07 13:30 ` Morten Brørup
2023-11-07 14:32 ` Konstantin Ananyev
2023-11-08 12:24 ` Tummala, Sivaprasad
2023-11-08 13:06 ` Morten Brørup
2023-11-09 16:43 ` Konstantin Ananyev
2023-10-17 10:58 ` Ferruh Yigit
2023-11-07 12:59 ` Konstantin Ananyev
2023-11-12 13:48 ` Thomas Monjalon
2023-12-20 7:10 Sivaprasad Tummala
2023-12-20 7:27 ` Morten Brørup
2023-12-20 9:22 ` Tummala, Sivaprasad
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=15039672.JCcGWNJJiE@thomas \
--to=thomas@monjalon.net \
--cc=Sivaprasad.Tummala@amd.com \
--cc=aconole@redhat.com \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@amd.com \
--cc=konstantin.v.ananyev@yandex.ru \
--cc=ktraynor@redhat.com \
--cc=maxime.coquelin@redhat.com \
--cc=mb@smartsharesystems.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).