[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 <tho...@monjalon.net> Sent: Friday, February 21, 2020 12:04 AM To: David Marchand <david.march...@redhat.com> Cc: dev@dpdk.org; acon...@redhat.com; ferruh.yi...@intel.com; Song, Keesang <keesang.s...@amd.com>; bl...@debian.org; ktray...@redhat.com; bruce.richard...@intel.com; honnappa.nagaraha...@arm.com; d...@linux.vnet.ibm.com; sta...@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?
