DPDK patches and discussions
 help / color / mirror / Atom feed
* [RFC PATCH 0/3] allow easier use of high lcore-ids
@ 2025-03-13 11:38 Bruce Richardson
  2025-03-13 11:38 ` [RFC PATCH 1/3] eal: centralize core parameter parsing Bruce Richardson
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Bruce Richardson @ 2025-03-13 11:38 UTC (permalink / raw)
  To: dev; +Cc: Bruce Richardson

Traditionally, DPDK has had a direct mapping of internal lcore-ids, to
the actual core numbers in use. With higher core count servers becoming
more prevalent the issue becomes one of increasing memory footprint when
using such a scheme, due to the need to have all arrays dimensioned for
all cores on the system, whether or not those cores are in use by the
app.

Therefore, the decision was made in the past to not expand the
build-time RTE_MAX_LCORE value beyond 128. Instead, it was recommended
that users use the "--lcores" EAL parameter to take the high-numbered
cores they wish to use and map them to lcore-ids within the 0 - 128
range. While this works, this is a little clunky as it means that
instead of just passing, for example, "-l 130-139", the user must
instead pass "--lcores 0@130,1@131,2@132,3@133,...."

This patchset attempts to simplify the situation by adding a new flag to
do this mapping automatically. To use cores 130-139 and map them to ids
0-9 internally, the EAL args now become: "-l 130-139 --map-lcore-ids".

Adding this new parameter required some rework of the existing arg
parsing code, because in current DPDK the args are parsed and checked in
the order they appear on the commandline. This means that using the
example above, the core parameter 130-139 will be rejected immediately
before the "map-lcore-ids" parameter is seen. To work around this, the
core (and service core) parameters are not parsed when seen, instead
they are only saved off and parsed after all arguments are parsed. The
"-l" and "-c" parameters are converted into "--lcores" arguments, so all
assigning of lcore ids is done there in all cases.

TODOs and requests-for-feedback:
- is there a suitable single-letter abbreviation we could use for this
  mapping option. For example, if using "x" it would mean we could use
  e.g. "-xl 130-139" for core options.
- still printfs in the code. This is to make it clearer for anyone
  testing what is happening.
- doc updates - will be done if feedback is positive to move from RFC to
  proper patch.

Bruce Richardson (3):
  eal: centralize core parameter parsing
  eal: convert core masks and lists to core sets
  eal: allow automatic mapping of high lcore ids

 drivers/event/dlb2/dlb2_priv.h             |   2 -
 drivers/event/dlb2/pf/base/dlb2_resource.c |  48 +--
 lib/eal/common/eal_common_options.c        | 338 +++++++--------------
 lib/eal/common/eal_options.h               |   2 +
 lib/eal/include/rte_eal.h                  |   2 +-
 5 files changed, 126 insertions(+), 266 deletions(-)

--
2.43.0


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2025-03-13 11:38 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-03-13 11:38 [RFC PATCH 0/3] allow easier use of high lcore-ids Bruce Richardson
2025-03-13 11:38 ` [RFC PATCH 1/3] eal: centralize core parameter parsing Bruce Richardson
2025-03-13 11:38 ` [RFC PATCH 2/3] eal: convert core masks and lists to core sets Bruce Richardson
2025-03-13 11:38 ` [RFC PATCH 3/3] eal: allow automatic mapping of high lcore ids Bruce Richardson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).