[dpdk-stable] [PATCH 1/4] eal/windows: fix cpuset macro name

[dpdk-stable] [PATCH 1/4] eal/windows: fix cpuset macro name

[David Marchand]

Fix the name of CPU_SETSIZE in hope we can reuse it in other parts of
the dpdk manipulating some rte_cpuset_t.

Fixes: 4dc2b4d2a4cd ("eal/windows: add headers for compatibility")
Cc: stable@dpdk.org

Signed-off-by: David Marchand <david.marchand@redhat.com>
---
 lib/librte_eal/windows/eal/include/sched.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/lib/librte_eal/windows/eal/include/sched.h b/lib/librte_eal/windows/eal/include/sched.h
index 257060594c..29868c93d1 100644
--- a/lib/librte_eal/windows/eal/include/sched.h
+++ b/lib/librte_eal/windows/eal/include/sched.h
@@ -14,8 +14,8 @@
 extern "C" {
 #endif
 
-#ifndef CPU_SET_SIZE
-#define CPU_SET_SIZE RTE_MAX_LCORE
+#ifndef CPU_SETSIZE
+#define CPU_SETSIZE RTE_MAX_LCORE
 #endif
 
 #define _BITS_PER_SET (sizeof(long long) * 8)
@@ -26,7 +26,7 @@ extern "C" {
 #define _WHICH_BIT(b) ((b) & (_BITS_PER_SET - 1))
 
 typedef struct _rte_cpuset_s {
-	long long _bits[_NUM_SETS(CPU_SET_SIZE)];
+	long long _bits[_NUM_SETS(CPU_SETSIZE)];
 } rte_cpuset_t;
 
 #define CPU_SET(b, s) ((s)->_bits[_WHICH_SET(b)] |= (1LL << _WHICH_BIT(b)))
@@ -35,7 +35,7 @@ typedef struct _rte_cpuset_s {
 	do {								\
 		unsigned int _i;					\
 									\
-		for (_i = 0; _i < _NUM_SETS(CPU_SET_SIZE); _i++)	\
+		for (_i = 0; _i < _NUM_SETS(CPU_SETSIZE); _i++)		\
 			(s)->_bits[_i] = 0LL;				\
 	} while (0)
 
-- 
2.23.0

Re: [dpdk-stable] [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE

[Thomas Monjalon]

Hi,

21/01/2020 01:24, Thomas Monjalon:
> 02/12/2019 16:35, David Marchand:
> > 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.
> > 
> > The --lcores does not need to care about the underlying cores, remove
> > this limitation.
> 
> > David Marchand (4):
> >   eal/windows: fix cpuset macro name
> >   eal: do not cache lcore detection state
> >   eal: display all detected cores at startup
> >   eal: remove limitation on cpuset with --lcores
> 
> The patches look good but it is very hard to review parsing code (last patch).
> We will better experience corner cases after merging.
> 
> Applied for -rc1, thanks

This patch was merged in 20.02.
We don't have any feedback about issues so it's probably working fine.

It is solving a problem for running DPDK on machines having a lot of cores.
Now the difficult question: is it a new feature or a fix?
Should we backport this patchset?

Re: [dpdk-stable] [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE

[Song, Keesang]

[AMD Official Use Only - Internal Distribution Only]

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.

-----Original Message-----
From: Thomas Monjalon <thomas@monjalon.net> 
Sent: Friday, February 21, 2020 12:04 AM
To: David Marchand <david.marchand@redhat.com>
Cc: dev@dpdk.org; aconole@redhat.com; ferruh.yigit@intel.com; Song, Keesang <Keesang.Song@amd.com>; bluca@debian.org; ktraynor@redhat.com; bruce.richardson@intel.com; honnappa.nagarahalli@arm.com; drc@linux.vnet.ibm.com; stable@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE

[CAUTION: External Email]

Hi,

21/01/2020 01:24, Thomas Monjalon:
> 02/12/2019 16:35, David Marchand:
> > 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.
> >
> > The --lcores does not need to care about the underlying cores, 
> > remove this limitation.
>
> > David Marchand (4):
> >   eal/windows: fix cpuset macro name
> >   eal: do not cache lcore detection state
> >   eal: display all detected cores at startup
> >   eal: remove limitation on cpuset with --lcores
>
> The patches look good but it is very hard to review parsing code (last patch).
> We will better experience corner cases after merging.
>
> Applied for -rc1, thanks

This patch was merged in 20.02.
We don't have any feedback about issues so it's probably working fine.

It is solving a problem for running DPDK on machines having a lot of cores.
Now the difficult question: is it a new feature or a fix?
Should we backport this patchset?

Re: [dpdk-stable] [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE

[David Marchand]

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?".


--
David Marchand

Re: [dpdk-stable] [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE

[Aaron Conole]

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

Re: [dpdk-stable] [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE

[Stephen Hemminger]

On Fri, 21 Feb 2020 09:48:58 -0500
Aaron Conole <aconole@redhat.com> wrote:

> 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  
> 

RTE_MAX_LCORES is exposed in API/ABI to application.
Many applications use that to size internal data structures.
Having rte_lcore_id() potentially return a larger value would cause
out of bounds access (and crash) in that application.

Re: [dpdk-stable] [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE

[Song, Keesang]

[AMD Official Use Only - Internal Distribution Only]

Hi Thomas & David,

We haven't got the final status on this patch, and I don't see this change even from the latest LTS 20.04 repo.
So I'd like to confirm whether this patch has been safely submitted to the main upstream.
Can you check the status of that commit?

https://patchwork.dpdk.org/patch/63507/

Thanks for your support in advance,
Keesang

-----Original Message-----
From: Thomas Monjalon <thomas@monjalon.net> 
Sent: Friday, February 21, 2020 12:04 AM
To: David Marchand <david.marchand@redhat.com>
Cc: dev@dpdk.org; aconole@redhat.com; ferruh.yigit@intel.com; Song, Keesang <Keesang.Song@amd.com>; bluca@debian.org; ktraynor@redhat.com; bruce.richardson@intel.com; honnappa.nagarahalli@arm.com; drc@linux.vnet.ibm.com; stable@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE

[CAUTION: External Email]

Hi,

21/01/2020 01:24, Thomas Monjalon:
> 02/12/2019 16:35, David Marchand:
> > 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.
> >
> > The --lcores does not need to care about the underlying cores, 
> > remove this limitation.
>
> > David Marchand (4):
> >   eal/windows: fix cpuset macro name
> >   eal: do not cache lcore detection state
> >   eal: display all detected cores at startup
> >   eal: remove limitation on cpuset with --lcores
>
> The patches look good but it is very hard to review parsing code (last patch).
> We will better experience corner cases after merging.
>
> Applied for -rc1, thanks

This patch was merged in 20.02.
We don't have any feedback about issues so it's probably working fine.

It is solving a problem for running DPDK on machines having a lot of cores.
Now the difficult question: is it a new feature or a fix?
Should we backport this patchset?

Re: [dpdk-stable] [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE

[Song, Keesang]

[AMD Public Use]

Hi Thomas & David,

We haven't got the final status on this patch, and I don't see this change even from the latest LTS 20.04 repo.
So I'd like to confirm whether this patch has been safely submitted to the main upstream.
Can you check the status of that commit?

https://patchwork.dpdk.org/patch/63507/

Thanks for your support in advance,
Keesang

-----Original Message-----
From: Thomas Monjalon <thomas@monjalon.net>
Sent: Friday, February 21, 2020 12:04 AM
To: David Marchand <david.marchand@redhat.com>
Cc: dev@dpdk.org; aconole@redhat.com; ferruh.yigit@intel.com; Song, Keesang <Keesang.Song@amd.com>; bluca@debian.org; ktraynor@redhat.com; bruce.richardson@intel.com; honnappa.nagarahalli@arm.com; drc@linux.vnet.ibm.com; stable@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE

[CAUTION: External Email]

Hi,

21/01/2020 01:24, Thomas Monjalon:
> 02/12/2019 16:35, David Marchand:
> > 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.
> >
> > The --lcores does not need to care about the underlying cores, 
> > remove this limitation.
>
> > David Marchand (4):
> >   eal/windows: fix cpuset macro name
> >   eal: do not cache lcore detection state
> >   eal: display all detected cores at startup
> >   eal: remove limitation on cpuset with --lcores
>
> The patches look good but it is very hard to review parsing code (last patch).
> We will better experience corner cases after merging.
>
> Applied for -rc1, thanks

This patch was merged in 20.02.
We don't have any feedback about issues so it's probably working fine.

It is solving a problem for running DPDK on machines having a lot of cores.
Now the difficult question: is it a new feature or a fix?
Should we backport this patchset?

Re: [dpdk-stable] [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE

[Thomas Monjalon]

29/05/2020 05:05, Song, Keesang:
> Hi Thomas & David,
> 
> We haven't got the final status on this patch, and I don't see this change even from the latest LTS 20.04 repo.
> So I'd like to confirm whether this patch has been safely submitted to the main upstream.
> Can you check the status of that commit?
> 
> https://patchwork.dpdk.org/patch/63507/

As you can see below, there is a pending question:
	"is it a new feature or a fix?"

Kevin and Luca are the arbiters for the backports in 18.11 and 19.11.


> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Friday, February 21, 2020 12:04 AM
> 
> Hi,
> 
> 21/01/2020 01:24, Thomas Monjalon:
> > 02/12/2019 16:35, David Marchand:
> > > 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.
> > >
> > > The --lcores does not need to care about the underlying cores, 
> > > remove this limitation.
> >
> > > David Marchand (4):
> > >   eal/windows: fix cpuset macro name
> > >   eal: do not cache lcore detection state
> > >   eal: display all detected cores at startup
> > >   eal: remove limitation on cpuset with --lcores
> >
> > The patches look good but it is very hard to review parsing code (last patch).
> > We will better experience corner cases after merging.
> >
> > Applied for -rc1, thanks
> 
> This patch was merged in 20.02.
> We don't have any feedback about issues so it's probably working fine.
> 
> It is solving a problem for running DPDK on machines having a lot of cores.
> Now the difficult question: is it a new feature or a fix?
> Should we backport this patchset?

Re: [dpdk-stable] [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE

[Song, Keesang]

[AMD Public Use]

Thanks Thomas for the response.
For a correction, the patchwork has not been submitted for the current LTS release, 19.11.2, but was merged into 20.02 and onward. 
The reason I brought this again was to address LTS users and many other application based on the LTS releases(18.11 & 19.11).
Since I found many of our customers and users are still relying on the latest LTS version, I'm seeking an aid for adding this change into at least 19.11, LTS branch.
We could argue that this is actually not a bug, in a way, it's inconvenient for Openstack or cloud deployed DPDK application since it's often inapt to change the base config and recompile the max lcore limit.
If backporting is still not a preferred way(pushing this patchwork into 19.11), then can we instead consider changing only the default value of ' CONFIG_RTE_MAX_LCORE' to 256 in common_base file?

# Compile Environment Abstraction Layer
#
CONFIG_RTE_MAX_LCORE=128 --> 256

I'd appreciate if anyone can advise me know what we can do about this to move forward.

-----Original Message-----
From: Thomas Monjalon <thomas@monjalon.net> 
Sent: Monday, June 1, 2020 2:23 PM
To: Song, Keesang <Keesang.Song@amd.com>
Cc: David Marchand <david.marchand@redhat.com>; dev@dpdk.org; aconole@redhat.com; ferruh.yigit@intel.com; bluca@debian.org; ktraynor@redhat.com; bruce.richardson@intel.com; honnappa.nagarahalli@arm.com; drc@linux.vnet.ibm.com; stable@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE

[CAUTION: External Email]

29/05/2020 05:05, Song, Keesang:
> Hi Thomas & David,
>
> We haven't got the final status on this patch, and I don't see this change even from the latest LTS 20.04 repo.
> So I'd like to confirm whether this patch has been safely submitted to the main upstream.
> Can you check the status of that commit?
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> hwork.dpdk.org%2Fpatch%2F63507%2F&amp;data=02%7C01%7CKeesang.Song%40am
> d.com%7Cd71ea9aca917447dfb3e08d80671f34c%7C3dd8961fe4884e608e11a82d994
> e183d%7C0%7C0%7C637266433776198364&amp;sdata=1EgxevCILVMMLgyQC%2FzaWYJ
> XJ%2BOijs0Rtym1TA0VS28%3D&amp;reserved=0

As you can see below, there is a pending question:
        "is it a new feature or a fix?"

Kevin and Luca are the arbiters for the backports in 18.11 and 19.11.


> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Friday, February 21, 2020 12:04 AM
>
> Hi,
>
> 21/01/2020 01:24, Thomas Monjalon:
> > 02/12/2019 16:35, David Marchand:
> > > 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.
> > >
> > > The --lcores does not need to care about the underlying cores, 
> > > remove this limitation.
> >
> > > David Marchand (4):
> > >   eal/windows: fix cpuset macro name
> > >   eal: do not cache lcore detection state
> > >   eal: display all detected cores at startup
> > >   eal: remove limitation on cpuset with --lcores
> >
> > The patches look good but it is very hard to review parsing code (last patch).
> > We will better experience corner cases after merging.
> >
> > Applied for -rc1, thanks
>
> This patch was merged in 20.02.
> We don't have any feedback about issues so it's probably working fine.
>
> It is solving a problem for running DPDK on machines having a lot of cores.
> Now the difficult question: is it a new feature or a fix?
> Should we backport this patchset?

Re: [dpdk-stable] [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE

[Song, Keesang]

[AMD Public Use]

Hi Kevin and Luca,

We are still waiting for the response.
Can you help on this for the backports in 18.11 and 19.11?
It would work for our customers even with changing the default value of ' CONFIG_RTE_MAX_LCORE' to 256 in common_base file in 18.11 and 19.11.

Thanks,
Keesang


-----Original Message-----
From: Song, Keesang 
Sent: Monday, June 1, 2020 3:54 PM
To: Thomas Monjalon <thomas@monjalon.net>
Cc: David Marchand <david.marchand@redhat.com>; dev@dpdk.org; aconole@redhat.com; ferruh.yigit@intel.com; bluca@debian.org; ktraynor@redhat.com; bruce.richardson@intel.com; honnappa.nagarahalli@arm.com; drc@linux.vnet.ibm.com; stable@dpdk.org; Aman Kumar <aman.kumar@vvdntech.in>; Grimm, Jon <Jon.Grimm@amd.com>
Subject: RE: [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE

[AMD Public Use]

Thanks Thomas for the response.
For a correction, the patchwork has not been submitted for the current LTS release, 19.11.2, but was merged into 20.02 and onward. 
The reason I brought this again was to address LTS users and many other application based on the LTS releases(18.11 & 19.11).
Since I found many of our customers and users are still relying on the latest LTS version, I'm seeking an aid for adding this change into at least 19.11, LTS branch.
We could argue that this is actually not a bug, in a way, it's inconvenient for Openstack or cloud deployed DPDK application since it's often inapt to change the base config and recompile the max lcore limit.
If backporting is still not a preferred way(pushing this patchwork into 19.11), then can we instead consider changing only the default value of ' CONFIG_RTE_MAX_LCORE' to 256 in common_base file?

# Compile Environment Abstraction Layer
#
CONFIG_RTE_MAX_LCORE=128 --> 256

I'd appreciate if anyone can advise me know what we can do about this to move forward.

-----Original Message-----
From: Thomas Monjalon <thomas@monjalon.net>
Sent: Monday, June 1, 2020 2:23 PM
To: Song, Keesang <Keesang.Song@amd.com>
Cc: David Marchand <david.marchand@redhat.com>; dev@dpdk.org; aconole@redhat.com; ferruh.yigit@intel.com; bluca@debian.org; ktraynor@redhat.com; bruce.richardson@intel.com; honnappa.nagarahalli@arm.com; drc@linux.vnet.ibm.com; stable@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE

[CAUTION: External Email]

29/05/2020 05:05, Song, Keesang:
> Hi Thomas & David,
>
> We haven't got the final status on this patch, and I don't see this change even from the latest LTS 20.04 repo.
> So I'd like to confirm whether this patch has been safely submitted to the main upstream.
> Can you check the status of that commit?
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> hwork.dpdk.org%2Fpatch%2F63507%2F&amp;data=02%7C01%7CKeesang.Song%40am
> d.com%7Cd71ea9aca917447dfb3e08d80671f34c%7C3dd8961fe4884e608e11a82d994
> e183d%7C0%7C0%7C637266433776198364&amp;sdata=1EgxevCILVMMLgyQC%2FzaWYJ
> XJ%2BOijs0Rtym1TA0VS28%3D&amp;reserved=0

As you can see below, there is a pending question:
        "is it a new feature or a fix?"

Kevin and Luca are the arbiters for the backports in 18.11 and 19.11.


> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Friday, February 21, 2020 12:04 AM
>
> Hi,
>
> 21/01/2020 01:24, Thomas Monjalon:
> > 02/12/2019 16:35, David Marchand:
> > > 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.
> > >
> > > The --lcores does not need to care about the underlying cores, 
> > > remove this limitation.
> >
> > > David Marchand (4):
> > >   eal/windows: fix cpuset macro name
> > >   eal: do not cache lcore detection state
> > >   eal: display all detected cores at startup
> > >   eal: remove limitation on cpuset with --lcores
> >
> > The patches look good but it is very hard to review parsing code (last patch).
> > We will better experience corner cases after merging.
> >
> > Applied for -rc1, thanks
>
> This patch was merged in 20.02.
> We don't have any feedback about issues so it's probably working fine.
>
> It is solving a problem for running DPDK on machines having a lot of cores.
> Now the difficult question: is it a new feature or a fix?
> Should we backport this patchset?

Re: [dpdk-stable] [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE

[Luca Boccassi]

On Tue, 2020-06-09 at 16:30 +0000, Song, Keesang wrote:
> [AMD Public Use]
> 
> Hi Kevin and Luca,
> 
> We are still waiting for the response.
> Can you help on this for the backports in 18.11 and 19.11?
> It would work for our customers even with changing the default value of ' CONFIG_RTE_MAX_LCORE' to 256 in common_base file in 18.11 and 19.11.
> 
> Thanks,
> Keesang

How to send patches for inclusion in LTS releases if not already
backported is documented here:

https://core.dpdk.org/contribute/#send

If you do the work to backport and test, on the surface it seems fine
to have those in 19.11.4

> -----Original Message-----
> From: Song, Keesang 
> Sent: Monday, June 1, 2020 3:54 PM
> To: Thomas Monjalon <thomas@monjalon.net>
> Cc: David Marchand <david.marchand@redhat.com>; dev@dpdk.org; aconole@redhat.com; ferruh.yigit@intel.com; bluca@debian.org; ktraynor@redhat.com; bruce.richardson@intel.com; honnappa.nagarahalli@arm.com; drc@linux.vnet.ibm.com; stable@dpdk.org; Aman Kumar <aman.kumar@vvdntech.in>; Grimm, Jon <Jon.Grimm@amd.com>
> Subject: RE: [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE
> 
> [AMD Public Use]
> 
> Thanks Thomas for the response.
> For a correction, the patchwork has not been submitted for the current LTS release, 19.11.2, but was merged into 20.02 and onward. 
> The reason I brought this again was to address LTS users and many other application based on the LTS releases(18.11 & 19.11).
> Since I found many of our customers and users are still relying on the latest LTS version, I'm seeking an aid for adding this change into at least 19.11, LTS branch.
> We could argue that this is actually not a bug, in a way, it's inconvenient for Openstack or cloud deployed DPDK application since it's often inapt to change the base config and recompile the max lcore limit.
> If backporting is still not a preferred way(pushing this patchwork into 19.11), then can we instead consider changing only the default value of ' CONFIG_RTE_MAX_LCORE' to 256 in common_base file?
> 
> # Compile Environment Abstraction Layer
> #
> CONFIG_RTE_MAX_LCORE=128 --> 256
> 
> I'd appreciate if anyone can advise me know what we can do about this to move forward.
> 
> -----Original Message-----
> From: Thomas Monjalon <thomas@monjalon.net>
> Sent: Monday, June 1, 2020 2:23 PM
> To: Song, Keesang <Keesang.Song@amd.com>
> Cc: David Marchand <david.marchand@redhat.com>; dev@dpdk.org; aconole@redhat.com; ferruh.yigit@intel.com; bluca@debian.org; ktraynor@redhat.com; bruce.richardson@intel.com; honnappa.nagarahalli@arm.com; drc@linux.vnet.ibm.com; stable@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE
> 
> [CAUTION: External Email]
> 
> 29/05/2020 05:05, Song, Keesang:
> > Hi Thomas & David,
> > 
> > We haven't got the final status on this patch, and I don't see this change even from the latest LTS 20.04 repo.
> > So I'd like to confirm whether this patch has been safely submitted to the main upstream.
> > Can you check the status of that commit?
> > 
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> > hwork.dpdk.org%2Fpatch%2F63507%2F&amp;data=02%7C01%7CKeesang.Song%40am
> > d.com%7Cd71ea9aca917447dfb3e08d80671f34c%7C3dd8961fe4884e608e11a82d994
> > e183d%7C0%7C0%7C637266433776198364&amp;sdata=1EgxevCILVMMLgyQC%2FzaWYJ
> > XJ%2BOijs0Rtym1TA0VS28%3D&amp;reserved=0
> 
> As you can see below, there is a pending question:
>         "is it a new feature or a fix?"
> 
> Kevin and Luca are the arbiters for the backports in 18.11 and 19.11.
> 
> 
> > -----Original Message-----
> > From: Thomas Monjalon <thomas@monjalon.net>
> > Sent: Friday, February 21, 2020 12:04 AM
> > 
> > Hi,
> > 
> > 21/01/2020 01:24, Thomas Monjalon:
> > > 02/12/2019 16:35, David Marchand:
> > > > 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.
> > > > 
> > > > The --lcores does not need to care about the underlying cores, 
> > > > remove this limitation.
> > > > David Marchand (4):
> > > >   eal/windows: fix cpuset macro name
> > > >   eal: do not cache lcore detection state
> > > >   eal: display all detected cores at startup
> > > >   eal: remove limitation on cpuset with --lcores
> > > 
> > > The patches look good but it is very hard to review parsing code (last patch).
> > > We will better experience corner cases after merging.
> > > 
> > > Applied for -rc1, thanks
> > 
> > This patch was merged in 20.02.
> > We don't have any feedback about issues so it's probably working fine.
> > 
> > It is solving a problem for running DPDK on machines having a lot of cores.
> > Now the difficult question: is it a new feature or a fix?
> > Should we backport this patchset?

Re: [dpdk-stable] [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE

[Kevin Traynor]

On 09/06/2020 18:48, Luca Boccassi wrote:
> On Tue, 2020-06-09 at 16:30 +0000, Song, Keesang wrote:
>> [AMD Public Use]
>>
>> Hi Kevin and Luca,
>>

Hi Keesang

>> We are still waiting for the response.
>> Can you help on this for the backports in 18.11 and 19.11?
>> It would work for our customers even with changing the default value of ' CONFIG_RTE_MAX_LCORE' to 256 in common_base file in 18.11 and 19.11.
>>
>> Thanks,
>> Keesang
> 
> How to send patches for inclusion in LTS releases if not already
> backported is documented here:
> 
> https://core.dpdk.org/contribute/#send
> 
> If you do the work to backport and test, on the surface it seems fine
> to have those in 19.11.4
> 

Looks ok to me too. I can take this in 18.11, but it will need to be in
19.11 first. Please send a backport for 18.11 and test that it's working
as expected with the 18.11 branch.

thanks,
Kevin.

>> -----Original Message-----
>> From: Song, Keesang 
>> Sent: Monday, June 1, 2020 3:54 PM
>> To: Thomas Monjalon <thomas@monjalon.net>
>> Cc: David Marchand <david.marchand@redhat.com>; dev@dpdk.org; aconole@redhat.com; ferruh.yigit@intel.com; bluca@debian.org; ktraynor@redhat.com; bruce.richardson@intel.com; honnappa.nagarahalli@arm.com; drc@linux.vnet.ibm.com; stable@dpdk.org; Aman Kumar <aman.kumar@vvdntech.in>; Grimm, Jon <Jon.Grimm@amd.com>
>> Subject: RE: [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE
>>
>> [AMD Public Use]
>>
>> Thanks Thomas for the response.
>> For a correction, the patchwork has not been submitted for the current LTS release, 19.11.2, but was merged into 20.02 and onward. 
>> The reason I brought this again was to address LTS users and many other application based on the LTS releases(18.11 & 19.11).
>> Since I found many of our customers and users are still relying on the latest LTS version, I'm seeking an aid for adding this change into at least 19.11, LTS branch.
>> We could argue that this is actually not a bug, in a way, it's inconvenient for Openstack or cloud deployed DPDK application since it's often inapt to change the base config and recompile the max lcore limit.
>> If backporting is still not a preferred way(pushing this patchwork into 19.11), then can we instead consider changing only the default value of ' CONFIG_RTE_MAX_LCORE' to 256 in common_base file?
>>
>> # Compile Environment Abstraction Layer
>> #
>> CONFIG_RTE_MAX_LCORE=128 --> 256
>>
>> I'd appreciate if anyone can advise me know what we can do about this to move forward.
>>
>> -----Original Message-----
>> From: Thomas Monjalon <thomas@monjalon.net>
>> Sent: Monday, June 1, 2020 2:23 PM
>> To: Song, Keesang <Keesang.Song@amd.com>
>> Cc: David Marchand <david.marchand@redhat.com>; dev@dpdk.org; aconole@redhat.com; ferruh.yigit@intel.com; bluca@debian.org; ktraynor@redhat.com; bruce.richardson@intel.com; honnappa.nagarahalli@arm.com; drc@linux.vnet.ibm.com; stable@dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH 0/4] Extend --lcores to run on cores > RTE_MAX_LCORE
>>
>> [CAUTION: External Email]
>>
>> 29/05/2020 05:05, Song, Keesang:
>>> Hi Thomas & David,
>>>
>>> We haven't got the final status on this patch, and I don't see this change even from the latest LTS 20.04 repo.
>>> So I'd like to confirm whether this patch has been safely submitted to the main upstream.
>>> Can you check the status of that commit?
>>>
>>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
>>> hwork.dpdk.org%2Fpatch%2F63507%2F&amp;data=02%7C01%7CKeesang.Song%40am
>>> d.com%7Cd71ea9aca917447dfb3e08d80671f34c%7C3dd8961fe4884e608e11a82d994
>>> e183d%7C0%7C0%7C637266433776198364&amp;sdata=1EgxevCILVMMLgyQC%2FzaWYJ
>>> XJ%2BOijs0Rtym1TA0VS28%3D&amp;reserved=0
>>
>> As you can see below, there is a pending question:
>>         "is it a new feature or a fix?"
>>
>> Kevin and Luca are the arbiters for the backports in 18.11 and 19.11.
>>
>>
>>> -----Original Message-----
>>> From: Thomas Monjalon <thomas@monjalon.net>
>>> Sent: Friday, February 21, 2020 12:04 AM
>>>
>>> Hi,
>>>
>>> 21/01/2020 01:24, Thomas Monjalon:
>>>> 02/12/2019 16:35, David Marchand:
>>>>> 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.
>>>>>
>>>>> The --lcores does not need to care about the underlying cores, 
>>>>> remove this limitation.
>>>>> David Marchand (4):
>>>>>   eal/windows: fix cpuset macro name
>>>>>   eal: do not cache lcore detection state
>>>>>   eal: display all detected cores at startup
>>>>>   eal: remove limitation on cpuset with --lcores
>>>>
>>>> The patches look good but it is very hard to review parsing code (last patch).
>>>> We will better experience corner cases after merging.
>>>>
>>>> Applied for -rc1, thanks
>>>
>>> This patch was merged in 20.02.
>>> We don't have any feedback about issues so it's probably working fine.
>>>
>>> It is solving a problem for running DPDK on machines having a lot of cores.
>>> Now the difficult question: is it a new feature or a fix?
>>> Should we backport this patchset?
>