Re: [PATCH v6 0/9] rework EAL argument parsing

[David Marchand <david.marchand@redhat.com>]

Hello Bruce,

On Tue, 22 Jul 2025 at 16:04, Bruce Richardson
<bruce.richardson@intel.com> wrote:
>
> 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.
>
> To improve this situation, this patchset 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, and two additional
> patches at the start of this set, this library 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 and the options list file.
> This single list with ifdefs makes it clear to the viewer what options
> are common across OS's, vs what are unix-only or linux-only.

I sent a few comments, but the series looks good to me up to HEAD~2.

I am still pondering on the new options as I don't see the need for
multiple options.

I have in mind the case when (containerised) dpdk applications are
started with no EAL core options, and they rely on cpu affinity and
EAL discovery.
For them, if we don't want to touch the default behavior of the -l
option, a simple -L ( / --lcore-remap) option would be enough.
And this -L option could accept an optional base value for remapping
to a certain range for multiprocess?


-- 
David Marchand