From: Bruce Richardson <bruce.richardson@intel.com>
To: dev@dpdk.org
Cc: david.marchand@redhat.com, Bruce Richardson <bruce.richardson@intel.com>
Subject: [RFC PATCH 0/7] rework EAL argument parsing in DPDK
Date: Tue, 20 May 2025 17:40:17 +0100 [thread overview]
Message-ID: <20250520164025.2055721-1-bruce.richardson@intel.com> (raw)
This RFC is just an initial prototype of one approach we may want to
take to help improve management of EAL cmdline arguments.
Although not complete (no account taken yet for BSD or Windows),
it's hopefully complete enough to give an idea of what I think would
improve the handling.
BACKGROUND:
- The first problem that led to this work was that of providing a
way for users to easily provide a set of CPU cores to DPDK where the
CPU ids are >= RTE_MAX_LCORE
- There are a number of solutions which were discussed for this, most
of which involved automatically remapping CPU ids to lcore ids
starting at zero.
- However, in discussion with David M. at the last DPDK Summit in
Prague, he pointed out the main difficulty with all these approaches
in that they don't work with multi-process, since we can't reuse lcore
id numbers in secondary process.
- This in turn lead to a realisation that when processing cmdline
arguments in DPDK, we always do so with very little context. So, for
example, when processing the "-l" flag, we have no idea whether there
will be later a --proc-type=secondary flag. We have all sorts of
post-arg-processing checks in place to try and catch these scenarios.
This patchset therefore tries to simplify the handling of argument
processing, by explicitly doing an initial pass to collate all arguments
into a structure. Thereafter, the actual arg parsing is done in a fixed
order, meaning that e.g. when processing the --main-lcore flag, we have
already processed the service core flags. We also can far quicker and
easier check for conflicting options, since they can all be checked for
NULL/non-NULL in the arg structure immediately after the struct has been
populated.
To do the initial argument gathering, this RFC uses the existing argparse
library in DPDK. With some minor tweaking, this meets our needs for EAL
argument parsing and allows us to not need to do direct getopt argument
processing inside EAL at all.
Bruce Richardson (7):
eal: add long options for each short option
argparse: add support for string and boolean args
argparse: make argparse EAL-args compatible
eal: define the EAL parameters in argparse format
eal: gather EAL args before processing
eal: combine parameter validation checks
eal: simplify handling of conflicting cmdline options
app/test/test_argparse.c | 46 +-
lib/argparse/rte_argparse.c | 46 +-
lib/argparse/rte_argparse.h | 9 +-
lib/eal/common/eal_common_memory.c | 3 +-
lib/eal/common/eal_common_options.c | 1435 ++++++++++++++++-----------
lib/eal/common/eal_options.h | 99 +-
lib/eal/common/eal_private.h | 11 +
lib/eal/linux/eal.c | 378 +------
lib/eal/meson.build | 2 +-
9 files changed, 966 insertions(+), 1063 deletions(-)
--
2.48.1
next reply other threads:[~2025-05-20 16:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-20 16:40 Bruce Richardson [this message]
2025-05-20 16:40 ` [RFC PATCH 1/7] eal: add long options for each short option Bruce Richardson
2025-05-20 16:40 ` [RFC PATCH 2/7] argparse: add support for string and boolean args Bruce Richardson
2025-05-20 16:40 ` [RFC PATCH 3/7] argparse: make argparse EAL-args compatible Bruce Richardson
2025-05-20 16:40 ` [RFC PATCH 4/7] eal: define the EAL parameters in argparse format Bruce Richardson
2025-05-20 16:40 ` [RFC PATCH 5/7] eal: gather EAL args before processing Bruce Richardson
2025-05-20 16:40 ` [RFC PATCH 6/7] eal: combine parameter validation checks Bruce Richardson
2025-05-20 16:40 ` [RFC PATCH 7/7] eal: simplify handling of conflicting cmdline options Bruce Richardson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250520164025.2055721-1-bruce.richardson@intel.com \
--to=bruce.richardson@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).