On Fri, Feb 21, 2020 at 9:19 AM Song, Keesang <keesang.s...@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
