> From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of David Marchand > Sent: Tuesday, January 14, 2020 1:59 PM > > On Mon, Dec 2, 2019 at 4:36 PM David Marchand > <david.march...@redhat.com> wrote: > > > > 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. > > Any comment? > Thanks. > > > -- > David Marchand >
I haven't reviewed the patch, but recall that the Mempool library sets up caches per lcore using hardcoded loops going from 0 to RTE_MAX_LCORE, regardless how many lcores are present and assigned to DPDK. Making rte_max_lcore dynamic (and possibly auto-detected by the EAL) instead of defined at compile time might also be an improvement for systems with fewer cores than RTE_MAX_LCORE. But there are probably a lot of considerations regarding multi-process applications. Med venlig hilsen / kind regards - Morten Brørup
