From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=CxN4ZoNG6vq0YqOtE/YFLo72qgkHz/TrAzqhKDOVQII=; b=vZU/u4kMrBezUTLQCrmd7rZl+cqWN4tPX8bUVZi++nRwOftEKODa4AgWUoG4vOjYzp ism1u1XnpSGjTh1K1KYKWJpUWVRJVsHFznlwWBE2eNXoU1Gtg1kKHxUMqz6HXNZPzgky HtES+z7VAKUVwv9r/YcAzCbYmxCL7bMSEFM0JSzfi3mNSwkZHAcdYpEbL1dmSG7zBG3M pe4Uu1TBtYGhNwMuo78s0FnQQsdrvu1D4xII1UGkkmH/VRFVux62gl3Q5oAwHbNwGW3x sEBhK+ffWy60wQdwp78dmXW6Uf5B/Lpx/w7H+/SEfJRBKK6/oruZp+FOsxhWWKMIoQAo +PMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=CxN4ZoNG6vq0YqOtE/YFLo72qgkHz/TrAzqhKDOVQII=; b=RNs/voW1GKe22ijzOeQLOX0uW8K1cTG7QB8P63GOsPt/1MT9Xeh+MKR+fHuhRLvegB xaWQynG+h7Rov1rETqSFZZGZ9Rivfw+BwLd1KLLy34vatKsc0Oq1qELIIo4xmt/WDW58 nX7g+XgVT97ksCfMvf5hMI026eQmqjJa3rL/OfP/yCOv6WYovys4yw/3un3MbqvIlrmi lrbj4ykO1fSi9A//MnKxZlncrlTUe7hilppGM04f8GN/X5YEbI+DmINkZ13ssPhy8fGE epm+sH85k325LYcJXgFG0UinCXKvnhM0h5dUPFrQ0oLbO/s2jMju1HxmmbsglxrvvEK2 0odA== X-Gm-Message-State: ALyK8tK234QazS4g2aK6+8X4w5x+nLd9l09hpcyMYF2GySnBfd1I124DlUQVkEhsVPktpP+cK0xJwQ3naCA1pA== X-Received: by 10.25.214.92 with SMTP id n89mr3012024lfg.162.1464859159599; Thu, 02 Jun 2016 02:19:19 -0700 (PDT) MIME-Version: 1.0 Sender: marc.sune@gmail.com Received: by 10.25.141.6 with HTTP; Thu, 2 Jun 2016 02:19:00 -0700 (PDT) In-Reply-To: <1809080.StTKWmco5F@xps13> References: <1809080.StTKWmco5F@xps13> From: Marc Date: Thu, 2 Jun 2016 11:19:00 +0200 X-Google-Sender-Auth: MDVCYvNeIPI26RH38v198XQ-zE4 Message-ID: To: Thomas Monjalon Cc: "Wiles, Keith" , Yuanhan Liu , dev@dpdk.org, "Richardson, Bruce" , "Tan, Jianfeng" , Stephen Hemminger , Christian Ehrhardt , Panu Matilainen , Olivier Matz Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [RFC] Yet another option for DPDK options X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 09:19:20 -0000 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