On Tue, 8 Jul 2025 17:20:34 +0000 Bruce Richardson <bruce.richard...@intel.com> wrote:
> This RFC is a second, more complete, prototype of one approach we may > want to take to help improve management of EAL cmdline arguments. > > 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 recent changes, this now meets our needs for EAL > argument parsing and allows us to not need to do direct getopt argument > processing inside EAL at all. > > An additional benefit of this work, is that the argument parsing for EAL > is much more centralised into common options. This reduces code a bit. > However, what is missing here is proper handling for unsupported options > across BSD and Windows. We can either take two approaches: > 1. just ifdef them out so they don't appear in the argparse list on > unsupported platforms, giving errors when used. > 2. keep them in the list of arguments, and ignore them (with warning) when > used on unsupported platforms. > The advantage of #1 is that it is simple and correct, but the advantage > of #2 is that is makes it easier to move scripts and commandline args > between platforms - but at the cost of the arg list shown by help to be > less accurate. > > Bruce Richardson (5): > eal: add long options for each short option > 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 > > lib/eal/common/eal_common_memory.c | 3 +- > lib/eal/common/eal_common_options.c | 1236 ++++++++++++++------------- > lib/eal/common/eal_options.h | 101 +-- > lib/eal/common/eal_private.h | 11 + > lib/eal/freebsd/eal.c | 164 +--- > lib/eal/linux/eal.c | 384 +-------- > lib/eal/linux/eal_memory.c | 2 +- > lib/eal/meson.build | 2 +- > lib/eal/windows/eal.c | 113 +-- > lib/meson.build | 1 + > 10 files changed, 726 insertions(+), 1291 deletions(-) > Could DPDK use a better 3rd party library for arparse like: https://github.com/cofyc/argparse that one is MIT license so free to reuse, etc. The project does have a bad habit of reinventing existing more complete existing libraries (for example RCU).
