From: Aaron Conole <email@example.com>
To: David Marchand <firstname.lastname@example.org>
Cc: "Song\, Keesang" <Keesang.Song@amd.com>,
Thomas Monjalon <email@example.com>,
"stable\@dpdk.org" <firstname.lastname@example.org>, "Grimm\,
Jon" <Jon.Grimm@amd.com>, "Hollingsworth\,
Subject: Re: [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE
Date: Fri, 21 Feb 2020 09:48:58 -0500 [thread overview]
Message-ID: <email@example.com> (raw)
In-Reply-To: <CAJFAV8xNp2LsStZ279iUydOd2Zbzj25ghrYDdnzPW54WTq8ayA@mail.gmail.com> (David Marchand's message of "Fri, 21 Feb 2020 10:40:09 +0100")
David Marchand <firstname.lastname@example.org> writes:
> On Fri, Feb 21, 2020 at 9:19 AM Song, Keesang <Keesang.Song@amd.com> wrote:
>> [AMD Official Use Only - Internal Distribution Only]
> Please, get this header removed.
> This is a public mailing list.
>> Thanks Thomas for bringing this up.
>> I consider this is not a new feature, but rather a fix to address
>> the issue with statically assigned maximum lcore limit on
>> high-density CPU platform such as AMD Epyc.
>> As I see a lot of DPDK adopters are still using LTS 18.11 & 19.11,
>> and they have 1~2 yrs of lifetime left, we like to backport this to
>> LTS 18.11 & 19.11 at least.
> It is not a fix.
> The use of static arrays is a design choice that goes back to the
> early days in dpdk.
> The addition of --lcores came in after this, but it was introduced for
> a different use case than placing lcores on any physical core.
> And there was no claim that a core > RTE_MAX_LCORE would be usable.
> When testing on a new hardware, it is normal to observe some limitations.
> Running DPDK on those platforms should be possible: "should be"
> because I do not have access to this hardware and saw neither tests
> reports nor performance numbers.
> Before this patch, the limitation is that on Epyc, cores >
> RTE_MAX_LCORE are not usable.
> Now, this change is quite constrained.
> If we backport it, I don't expect issues in the main dpdk components
> (based on code review and ovs tests with a RTE_MAX_LCORE set to 16 on
> a 24 cores system).
> There might be issues in some examples or not widely used library
> which uses a physical core id instead of a lcore id.
> This is the same recurring question "do we allow new features in a
> stable branch?".
Usually, the answer is 'no'. But we do allow some "new" things to be
backported (pci ids, etc) that might be required to enable older
functionality. Additionally, I'm sure if some feature were required to
mitigate a CVE, we'd rather favor backporting it.
I guess we could pose a litmus test:
1. Is the problem this feature solves so widespread that it needs to
be addressed ASAP?
2. Is there a known workaround to the problem this is solving?
3. How intrusive is the feature?
4. Is it shown to be stable in the mainline (number of fixes, testing,
5. Is it constrained enough that we know we can support it with even
higher priority than other things?
Probably other questions that will need to be asked.
And even in that list of question, I'm not sure I'd be able to advocate
backporting this in the upstream branches - it hasn't had much testing.
It's unstable. It's "difficult" to use. It is not widespread that
people have so many cores. The workaround is much simpler than
supporting this (recompile).
> David Marchand
next prev parent reply other threads:[~2020-02-21 14:49 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
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 [this message]
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
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).