[RFC PATCH v2 0/5] rework EAL argument parsing in DPDK

[Bruce Richardson]

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(-)

-- 
2.48.1