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

[David Marchand]

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?


-- 
David Marchand