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 <tho...@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?