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

[Bruce Richardson <bruce.richardson@intel.com>]

On Tue, Sep 30, 2025 at 03:06:14PM +0200, David Marchand wrote:
> 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?
> 

That can work, but the complication is that -l option allows remapping
within it, and the interactions get complicated. So we'd have to disallow
the advanced remapping syntax with the -l option. That should be doable, I
suppose. Let me investigate and respin.

/Bruce