From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc Subject: Re: [RFC] Yet another option for DPDK options Date: Thu, 2 Jun 2016 11:19:00 +0200 Message-ID: References: <1809080.StTKWmco5F@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: "Wiles, Keith" , Yuanhan Liu , dev@dpdk.org, "Richardson, Bruce" , "Tan, Jianfeng" , Stephen Hemminger , Christian Ehrhardt , Panu Matilainen , Olivier Matz To: Thomas Monjalon Return-path: Received: from mail-lf0-f65.google.com (mail-lf0-f65.google.com [209.85.215.65]) by dpdk.org (Postfix) with ESMTP id F1E313792 for ; Thu, 2 Jun 2016 11:19:19 +0200 (CEST) Received: by mail-lf0-f65.google.com with SMTP id w16so4459392lfd.0 for ; Thu, 02 Jun 2016 02:19:19 -0700 (PDT) In-Reply-To: <1809080.StTKWmco5F@xps13> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 1 June 2016 at 20:51, Thomas Monjalon wrote: > Hi Keith, > > I'll try to bring more context to this discussion below. > > 2016-06-01 15:00, Wiles, Keith: > > Started from the link below, but did not want to highjack the thread. > > http://dpdk.org/ml/archives/dev/2016-June/040021.html > > > > I was thinking about this problem from a user perspective and command > > line options are very difficult to manage specifically when you have > > a large number of options as we have in dpdk. > > The user uses an application. > It is up to the application to let users do some configuration. > > > I see all of these options as a type of database of information for > > the DPDK and the application, because the application command line > > options are also getting very complex as well. > > DPDK is a collection of libraries. > There is no command line options in a library. > So we should not be talking about such issue. But... > > ... configuration of the DPDK libraries must be improved. > We need some clean API to let the application configure a lot of things > at runtime (during initialization or after). > Ideally the API should not use an argc/argv format. > > We also have a lot of applications for tests or examples which use a > common configuration scheme based on command line options. > It is only for test and demonstration purpose. So it is not so important > and must not be complex to maintain. > I also think that we should avoid having to modify a configuration file > for test applications. I like launching a freshly built testpmd with a > copy-pasted command line without having to create a temporary > configuration file. > > Instead of wrapping a messy configuration interface, we should proceed > with this steps (in this order): > - implement clean configuration API > - move command line options parsing in a separate library > - implement an alternative to the options parsing library, as an example > - remove the options parsing library if the alternative is better > > Fully agree on all that you say. To me: * +1 on staying away from XML and JSON. * INI is an option, but if there is the need of hierarchical another option is libconfig ( http://www.hyperrealm.com/libconfig/libconfig_manual.html#Configuration-Files) that to me is more readable and user-friendly than JSON (not to mention XML). * As you, Thomas say, and as it has been discussed previously [1]; it would be good that eal_init was not depending on argv and had a _simple_, and with reasonable defaults, struct-based init API, and build wrapper libraries on top of that, one being the command-line and another being a configuration file (although they would be connected somehow). Marc [1] http://dpdk.org/ml/archives/dev/2013-August/000374.html