From: Thomas Monjalon <thomas@monjalon.net>
To: Euan Bourke <euan.bourke@intel.com>,
Bruce Richardson <bruce.richardson@intel.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>, dev@dpdk.org
Subject: Re: [PATCH v4 0/8] add new command line argument parsing library
Date: Wed, 24 Jan 2024 14:33:59 +0100 [thread overview]
Message-ID: <18366886.sWSEgdgrri@thomas> (raw)
In-Reply-To: <ZYAOXRwVYJMMEV5l@bricha3-MOBL.ger.corp.intel.com>
18/12/2023 10:18, Bruce Richardson:
> On Fri, Dec 15, 2023 at 01:53:21PM -0800, Stephen Hemminger wrote:
> > On Fri, 15 Dec 2023 17:26:24 +0000
> > Euan Bourke <euan.bourke@intel.com> wrote:
> >
> > > A recent thread on the mailing list[1] discussed corelist and coremask
> > > parsing and the idea of a new library dedicated to command line parsing
> > > was mentioned[2]. This patchset adds the library, along with the new
> > > APIs, and edits the existing EAL, DLB2 driver and some example
> > > application functions to use these APIs, rather than each implementing
> > > their own copies.
> > >
> > > The new APIs work similar to the existing functions in EAL, however
> > > instead of filling a core array like this:
> > > [1, -1, -1, 2, 3] (a non -1 refers to an 'active core' at that index)
> > > It fills it like this:
> > > [0, 3, 4] (with the value at each index being an 'active core').
> > >
> > > The new APIs will also return the number of cores contained in the
> > > passed corelist/coremask, so in the above example, 3 would be returned.
> > >
> > > Also included in this patchest is a heuristic parser which searches
> > > for key markers in the core string, returning a enum value based off
> > > this search to indicate if a parameter is likely a coremask or a
> > > corelist. This heuristic function is also wrapped in a parser
> > > function allowing apps to handle both coremasks and corelists
> > > simultaneously.
> > >
> > > [1] https://mails.dpdk.org/archives/dev/2023-November/280957.html
> > > [2] https://mails.dpdk.org/archives/dev/2023-November/280966.html
> > >
> >
> > The code is ok, but the naming needs to change.
> >
> > To me the name argparse implies that library implements something
> > similar to Python argparse. But that isn't what this library does.
> > It seems limited to just cpu masks. Perhaps cpuparse would be better name
> > or make it part of a larger implementation of a full library
> > more like Python argparse.
>
> Yes, it is a limited set of functions, so the name is probably not ideal if
> that's what it's going to remaini (though what library ever stays
> un-expanded once started!).
This is a string parsing library.
> I think we need a general discussion
> on-list and probably in tech-board too about argument handling, since in
> the last couple of months there have been no less than 3 separate
> independent proposals around functionality for arguments.
>
> There has been:
> * This set, for extracting out functions for processing coremask and
> corelist arguments. Presumably other argument parsing types may look to
> be included in future e.g. device args, perhaps.
> * A set from me [1], looking to take the slightly opposite side of things, and
> make it easier for apps to initialize EAL with a custom argument set. So
> it can be thought of as an argument-list management library.
> * An "argparse" library from Chengwen [2] which does what you describe
> above and be a C implementation like the python argparse module.
>
> We need to decide how to manage all these three, if we want to take them
> all, and if they should all be merged into a single library, or some kept
> separate from others.
Yes, we need to decide whether we want to keep this string parsing
as a standalone library, or we prefer to integrate it in Chengwen's
global argument parsing library.
The question is do we want to do string parsing out of the global argument parsing?
I suppose the answer is yes, at least when parsing devargs in drivers.
In this case we need this library to be standalone (and reused in Chengwen's argparse).
next prev parent reply other threads:[~2024-01-24 13:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <https://inbox.dpdk.org/dev/20231207161818.2590661-1-euan.bourke@intel.com/>
2023-12-15 17:26 ` Euan Bourke
2023-12-15 17:26 ` [PATCH v4 1/8] arg_parser: new library for command line parsing Euan Bourke
2024-01-24 13:16 ` Morten Brørup
2024-01-24 13:31 ` Bruce Richardson
2023-12-15 17:26 ` [PATCH v4 2/8] arg_parser: add new coremask parsing API Euan Bourke
2023-12-15 17:26 ` [PATCH v4 3/8] eal: add support for new arg parsing library Euan Bourke
2023-12-15 17:26 ` [PATCH v4 4/8] eal: update to service core related parsers Euan Bourke
2023-12-15 17:26 ` [PATCH v4 5/8] event/dlb2: add new arg parsing library API support Euan Bourke
2023-12-15 17:26 ` [PATCH v4 6/8] arg_parser: added common core string and heuristic parsers Euan Bourke
2023-12-15 17:26 ` [PATCH v4 7/8] examples/eventdev_pipeline: update to call arg parser API Euan Bourke
2023-12-15 17:26 ` [PATCH v4 8/8] examples/l3fwd-power: " Euan Bourke
2023-12-18 3:14 ` Tummala, Sivaprasad
2023-12-15 21:53 ` [PATCH v4 0/8] add new command line argument parsing library Stephen Hemminger
2023-12-18 9:18 ` Bruce Richardson
2024-01-24 13:33 ` Thomas Monjalon [this message]
2024-02-14 17:01 ` Thomas Monjalon
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=18366886.sWSEgdgrri@thomas \
--to=thomas@monjalon.net \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=euan.bourke@intel.com \
--cc=stephen@networkplumber.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).