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

[David Marchand]

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.

#2 makes sense if we intend to implement those Linux options in other
OS, but I don't see this coming (I would rather remove options in
general).
So I prefer something like #1.


About patch 1, please update doc/guides/linux_gsg/eal_args.include.rst
(this file needs some fixes as well, like the --log* options are not
documented, this is a separate topic).

About patch 2 where the options are declared, --socket-* options got
renamed as --numa-* recently.

In this same patch, I see little differences in option descriptions.
Those tweaks are easier to read, but some details are lost and not
covered in doc/guides/linux_gsg/eal_args.include.rst (resp.
linux_eal_parameters.rst for Linux only options).
For example, our doc does not describe --log-level=help.

Patch 3 removed the rte_usage_hook_t stuff, this must be restored for
applications that rely on this.

I also see a difference in the cpu discovery logs that disappeared
after the series, I did not investigate why.
EAL: Detected CPU lcores: 16
EAL: Detected NUMA nodes: 1


The rest of the series looks like a good refactoring.
Thanks for the cleanup.


-- 
David Marchand