From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [RFC] Yet another option for DPDK options Date: Wed, 01 Jun 2016 20:51:45 +0200 Message-ID: <1809080.StTKWmco5F@xps13> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: Yuanhan Liu , dev@dpdk.org, "Richardson, Bruce" , "Tan, Jianfeng" , Stephen Hemminger , Christian Ehrhardt , Panu Matilainen , Olivier Matz To: "Wiles, Keith" Return-path: Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46]) by dpdk.org (Postfix) with ESMTP id B14826939 for ; Wed, 1 Jun 2016 20:51:47 +0200 (CEST) Received: by mail-wm0-f46.google.com with SMTP id z87so41388794wmh.0 for ; Wed, 01 Jun 2016 11:51:47 -0700 (PDT) In-Reply-To: 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" 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