patches for DPDK stable branches
 help / color / mirror / Atom feed
From: Aaron Conole <aconole@redhat.com>
To: David Marchand <david.marchand@redhat.com>
Cc: "Song\, Keesang" <Keesang.Song@amd.com>,
	"ktraynor\@redhat.com" <ktraynor@redhat.com>,
	"bluca\@debian.org" <bluca@debian.org>,
	Thomas Monjalon <thomas@monjalon.net>,
	"dev\@dpdk.org" <dev@dpdk.org>,
	"ferruh.yigit\@intel.com" <ferruh.yigit@intel.com>,
	"bruce.richardson\@intel.com" <bruce.richardson@intel.com>,
	"honnappa.nagarahalli\@arm.com" <honnappa.nagarahalli@arm.com>,
	"drc\@linux.vnet.ibm.com" <drc@linux.vnet.ibm.com>,
	"stable\@dpdk.org" <stable@dpdk.org>, "Grimm\,
	Jon" <Jon.Grimm@amd.com>, "Hollingsworth\,
	Brent" <brent.hollingsworth@amd.com>
Subject: Re: [dpdk-stable] [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: <f7t36b4c7xh.fsf@dhcp-25.97.bos.redhat.com> (raw)
In-Reply-To: <CAJFAV8xNp2LsStZ279iUydOd2Zbzj25ghrYDdnzPW54WTq8ayA@mail.gmail.com> (David Marchand's message of "Fri, 21 Feb 2020 10:40:09 +0100")

David Marchand <david.marchand@redhat.com> 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,
     etc)?
  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


  reply	other threads:[~2020-02-21 14:49 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20191202153559.9709-1-david.marchand@redhat.com>
2019-12-02 15:41 ` [dpdk-stable] [PATCH 1/4] eal/windows: fix cpuset macro name David Marchand
     [not found] ` <2076701.vBoWY3egPC@xps>
2020-02-21  8:04   ` [dpdk-stable] [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE 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

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=f7t36b4c7xh.fsf@dhcp-25.97.bos.redhat.com \
    --to=aconole@redhat.com \
    --cc=Jon.Grimm@amd.com \
    --cc=Keesang.Song@amd.com \
    --cc=bluca@debian.org \
    --cc=brent.hollingsworth@amd.com \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=drc@linux.vnet.ibm.com \
    --cc=ferruh.yigit@intel.com \
    --cc=honnappa.nagarahalli@arm.com \
    --cc=ktraynor@redhat.com \
    --cc=stable@dpdk.org \
    --cc=thomas@monjalon.net \
    /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).