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.
#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
