[RFC PATCH v2 0/5] rework EAL argument parsing in DPDK

[Bruce Richardson]

On Wed, Jul 09, 2025 at 02:30:42PM +0200, David Marchand wrote:
> Hi Bruce,
> 
> On Tue, Jul 8, 2025 at 7:21 PM Bruce Richardson
> <bruce.richardson at 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(-)
> 
> Thanks for working on this topic.
> I will review it soon, after v25.07.
> 
> ASan complains about this series, as some memory gets leaked, could
> you have a look?
> 
Sure, I'll take a look before I do a non-RFC version.

However, I'll wait feedback on whether this is a direction we want to take
or not, before I do any more revisions of it.