[24.03,RFC,0/3] Add argument manipulation library

Message ID 20231102172849.7400-1-bruce.richardson@intel.com (mailing list archive)
Headers
Series Add argument manipulation library |

Message

Bruce Richardson Nov. 2, 2023, 5:28 p.m. UTC
  DPDK has traditionally assumed that apps are written where argc/argv
parameters are passed directly to rte_eal_init() and then app arguments
are handled afterwards, as is done in the DPDK apps and examples.

However, based on other projects, like VPP and OVS, we know that this is
often not the case. Instead, the apps build up argument lists internally
themselves and pass those to the init function, and DPDK never directly
accesses the real argc/argv values.

Therefore, let's make this mode of operation a little easier to use, by
adding in an args library to allow an app to dynamically build up an
args array and then pass that to EAL init. This library allows things
like, for example, initializing a list from argv and then checking if a
particular parameter is present, adding it if not. All the basics of
such a library are included in patch 1, and I've found it of use myself
when writing some simple apps internally using DPDK.

Patches 2 and 3 go a little further than this, and allow for a slightly
different use-case, that where an app may want to allow mixing of EAL
arguments in with app args. These patches allow the user to query if a
particular argument is an EAL arg or not, or a valid app argument. The
idea here would be, that an app could go through it's argument list,
building up an argument list for EAL init by just picking out the EAL
arguments from a full argument list. I'm less convinced of the value of
this compared to the basics in patch 1, but I think the idea is
interesting so seeking feedback on it.

Bruce Richardson (3):
  args: new library to allow easier manipulation of cmdline args
  eal: allow export of the cmdline argument parsing options
  args: add functions to check parameter validity

 doc/api/doxy-api-index.md           |   1 +
 doc/api/doxy-api.conf.in            |   1 +
 lib/args/args.c                     | 301 ++++++++++++++++++++++++++++
 lib/args/meson.build                |   5 +
 lib/args/rte_args.h                 | 255 +++++++++++++++++++++++
 lib/args/version.map                |  22 ++
 lib/eal/common/eal_common_options.c |   9 +
 lib/eal/include/rte_eal.h           |  14 ++
 lib/eal/version.map                 |   1 +
 lib/meson.build                     |   2 +
 10 files changed, 611 insertions(+)
 create mode 100644 lib/args/args.c
 create mode 100644 lib/args/meson.build
 create mode 100644 lib/args/rte_args.h
 create mode 100644 lib/args/version.map

--
2.39.2
  

Comments

Stephen Hemminger Nov. 2, 2023, 5:50 p.m. UTC | #1
On Thu,  2 Nov 2023 17:28:46 +0000
Bruce Richardson <bruce.richardson@intel.com> wrote:

> DPDK has traditionally assumed that apps are written where argc/argv
> parameters are passed directly to rte_eal_init() and then app arguments
> are handled afterwards, as is done in the DPDK apps and examples.
> 
> However, based on other projects, like VPP and OVS, we know that this is
> often not the case. Instead, the apps build up argument lists internally
> themselves and pass those to the init function, and DPDK never directly
> accesses the real argc/argv values.
> 
> Therefore, let's make this mode of operation a little easier to use, by
> adding in an args library to allow an app to dynamically build up an
> args array and then pass that to EAL init. This library allows things
> like, for example, initializing a list from argv and then checking if a
> particular parameter is present, adding it if not. All the basics of
> such a library are included in patch 1, and I've found it of use myself
> when writing some simple apps internally using DPDK.
> 
> Patches 2 and 3 go a little further than this, and allow for a slightly
> different use-case, that where an app may want to allow mixing of EAL
> arguments in with app args. These patches allow the user to query if a
> particular argument is an EAL arg or not, or a valid app argument. The
> idea here would be, that an app could go through it's argument list,
> building up an argument list for EAL init by just picking out the EAL
> arguments from a full argument list. I'm less convinced of the value of
> this compared to the basics in patch 1, but I think the idea is
> interesting so seeking feedback on it.
> 
> Bruce Richardson (3):
>   args: new library to allow easier manipulation of cmdline args
>   eal: allow export of the cmdline argument parsing options
>   args: add functions to check parameter validity
> 
>  doc/api/doxy-api-index.md           |   1 +
>  doc/api/doxy-api.conf.in            |   1 +
>  lib/args/args.c                     | 301 ++++++++++++++++++++++++++++
>  lib/args/meson.build                |   5 +
>  lib/args/rte_args.h                 | 255 +++++++++++++++++++++++
>  lib/args/version.map                |  22 ++
>  lib/eal/common/eal_common_options.c |   9 +
>  lib/eal/include/rte_eal.h           |  14 ++
>  lib/eal/version.map                 |   1 +
>  lib/meson.build                     |   2 +
>  10 files changed, 611 insertions(+)
>  create mode 100644 lib/args/args.c
>  create mode 100644 lib/args/meson.build
>  create mode 100644 lib/args/rte_args.h
>  create mode 100644 lib/args/version.map
> 
> --
> 2.39.2
> 

It would be good to change rte_eal_init() from:
int rte_eal_init(int argc, char **argv);

to
int rte_eal_init(int argc, char * const *argv);

I.e it should not modify the argv's passed.
This would save unnecessary copy in applications that build synthetic args.
Example already exists in dumpcap.
  
Bruce Richardson Nov. 2, 2023, 6:12 p.m. UTC | #2
On Thu, Nov 02, 2023 at 10:50:29AM -0700, Stephen Hemminger wrote:
> On Thu,  2 Nov 2023 17:28:46 +0000
> Bruce Richardson <bruce.richardson@intel.com> wrote:
> 
> > DPDK has traditionally assumed that apps are written where argc/argv
> > parameters are passed directly to rte_eal_init() and then app arguments
> > are handled afterwards, as is done in the DPDK apps and examples.
> > 
> > However, based on other projects, like VPP and OVS, we know that this is
> > often not the case. Instead, the apps build up argument lists internally
> > themselves and pass those to the init function, and DPDK never directly
> > accesses the real argc/argv values.
> > 
> > Therefore, let's make this mode of operation a little easier to use, by
> > adding in an args library to allow an app to dynamically build up an
> > args array and then pass that to EAL init. This library allows things
> > like, for example, initializing a list from argv and then checking if a
> > particular parameter is present, adding it if not. All the basics of
> > such a library are included in patch 1, and I've found it of use myself
> > when writing some simple apps internally using DPDK.
> > 
> > Patches 2 and 3 go a little further than this, and allow for a slightly
> > different use-case, that where an app may want to allow mixing of EAL
> > arguments in with app args. These patches allow the user to query if a
> > particular argument is an EAL arg or not, or a valid app argument. The
> > idea here would be, that an app could go through it's argument list,
> > building up an argument list for EAL init by just picking out the EAL
> > arguments from a full argument list. I'm less convinced of the value of
> > this compared to the basics in patch 1, but I think the idea is
> > interesting so seeking feedback on it.
> > 
> > Bruce Richardson (3):
> >   args: new library to allow easier manipulation of cmdline args
> >   eal: allow export of the cmdline argument parsing options
> >   args: add functions to check parameter validity
> > 
> >  doc/api/doxy-api-index.md           |   1 +
> >  doc/api/doxy-api.conf.in            |   1 +
> >  lib/args/args.c                     | 301 ++++++++++++++++++++++++++++
> >  lib/args/meson.build                |   5 +
> >  lib/args/rte_args.h                 | 255 +++++++++++++++++++++++
> >  lib/args/version.map                |  22 ++
> >  lib/eal/common/eal_common_options.c |   9 +
> >  lib/eal/include/rte_eal.h           |  14 ++
> >  lib/eal/version.map                 |   1 +
> >  lib/meson.build                     |   2 +
> >  10 files changed, 611 insertions(+)
> >  create mode 100644 lib/args/args.c
> >  create mode 100644 lib/args/meson.build
> >  create mode 100644 lib/args/rte_args.h
> >  create mode 100644 lib/args/version.map
> > 
> > --
> > 2.39.2
> > 
> 
> It would be good to change rte_eal_init() from:
> int rte_eal_init(int argc, char **argv);
> 
> to
> int rte_eal_init(int argc, char * const *argv);
> 
> I.e it should not modify the argv's passed.
> This would save unnecessary copy in applications that build synthetic args.
> Example already exists in dumpcap.
> 

Pushed up a quick patch proposal for that:
http://patches.dpdk.org/project/dpdk/patch/20231102181148.56930-1-bruce.richardson@intel.com/