On Wed, Jul 09, 2025 at 02:30:42PM +0200, David Marchand wrote: > Hi Bruce, > > On Tue, Jul 8, 2025 at 7:21 PM Bruce Richardson > <bruce.richard...@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? > Sure, I'll take a look before I do a non-RFC version.
However, I'll wait feedback on whether this is a direction we want to take or not, before I do any more revisions of it.
