DPDK patches and discussions
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: dev@dpdk.org
Subject: Re: [24.03 RFC 0/3] Add argument manipulation library
Date: Thu, 2 Nov 2023 10:50:29 -0700	[thread overview]
Message-ID: <20231102105029.2c9eff43@fedora> (raw)
In-Reply-To: <20231102172849.7400-1-bruce.richardson@intel.com>

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.


  parent reply	other threads:[~2023-11-02 17:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-02 17:28 Bruce Richardson
2023-11-02 17:28 ` [24.03 RFC 1/3] args: new library to allow easier manipulation of cmdline args Bruce Richardson
2024-01-24 12:03   ` Thomas Monjalon
2024-01-24 13:57     ` Honnappa Nagarahalli
2023-11-02 17:28 ` [24.03 RFC 2/3] eal: allow export of the cmdline argument parsing options Bruce Richardson
2023-11-02 17:28 ` [24.03 RFC 3/3] args: add functions to check parameter validity Bruce Richardson
2024-01-24 11:53   ` Thomas Monjalon
2023-11-02 17:50 ` Stephen Hemminger [this message]
2023-11-02 18:12   ` [24.03 RFC 0/3] Add argument manipulation library Bruce Richardson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231102105029.2c9eff43@fedora \
    --to=stephen@networkplumber.org \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).