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 > <[email protected]> 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
