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

Thomas Monjalon thomas at monjalon.net
Mon Jun 1 23:22:52 CEST 2020


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





More information about the dev mailing list