On Fri, May 02, 2025 at 04:11:34PM +0100, Bruce Richardson wrote: > When attempting to run DPDK with cpu ids > RTE_MAX_LCORE, it can be > awkward to build up a command-line parameter specifying the cpu to lcore > mappings core-by-core. To simplify things for the common case, add in > the -L, --lcores-automap option, to take a list of cpu ids, which may or > may not be >= RTE_MAX_LCORE, and map them to lcore ids starting at zero. > > For example, running lcores_autotest with dpdk-test on cores 140-143 > with a build where RTE_MAX_LCORE is 128, is now as simple as: > > $ ./dpdk-test -L 140-143 -- lcores_autotest > ... > EAL threads count: 4, RTE_MAX_LCORE=128 > lcore 0, socket 1, role RTE, cpuset 140 > lcore 1, socket 1, role RTE, cpuset 141 > lcore 2, socket 1, role RTE, cpuset 142 > lcore 3, socket 1, role RTE, cpuset 143 > ... > > Signed-off-by: Bruce Richardson <bruce.richard...@intel.com> > --- > doc/guides/linux_gsg/eal_args.include.rst | 16 +++++- > lib/eal/common/eal_common_options.c | 69 +++++++++++++++++++++-- > lib/eal/common/eal_options.h | 2 + > lib/eal/windows/include/sched.h | 1 + > 4 files changed, 81 insertions(+), 7 deletions(-) > There is (I think) the skeleton of a good solution in this patcht, but there are more conditions to be considered and thought of yet. Specifically the needs of multi-process, where a secondary cannot re-use lcore ids in the primary, needs to be taken into account.
Another scenario not accounted for here, is the one where the user runs the app using "taskset" rather than specifying an lcore id. Using taskset with cores >RTE_MAX_LCORE currently doesn't work, and this patch doesn't fix it. Therefore, for simplicity, I'm dropping this (patch 4) from v4 of this set, while investigating how we can improve things a bit further. I will start a new series with any futher work I get done in this release. /Bruce
