From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=74rnRjDqHjjrn8tAxjpQnKaOt5225YwbGp/CUZtG4/U=; b=qcrT+zJR21g3tBl+hFKc59ZQvEGvOrruSyD9fmfVvnHvwZwT9QIDPqlz/vKMZ03/q5 XZuu6anVmncArdqD45VyvgFigU3Tz3KIb+c22Nk8YZjKQ2cmabm9hzi3HbRYf1WwfRas KH7ubxKkZKdOY/3SLgeFLOMRzwmo8K8FAugKb4pznJt1IQEaIJGnwrGhXoGXHE1ANRWb e+ixRZkr9YeAl3DXtSJary6R//DYLBiQw1QjAh7itSGYpyQDQ0fcMQ3CFaClYkAT0rvW doC5+SEaljvNqBFIhLInFArDuNm2BVMzn0IExXjgI9oqwrJ2SLLcbt9EDA9ShIYN4TGg nEXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=74rnRjDqHjjrn8tAxjpQnKaOt5225YwbGp/CUZtG4/U=; b=Kvri9j6TnnF5A5ozGfhRiyJuh9TEOBX+SlskB84MMMT/VpqqefdXQhBn7MBwLiRwlf qf/QGCZW49piOt6wM/PPKuhrNNeoFFvf4dTDsZEPJbVtbTMluRFokDGwU4W09K+3RYEb KQtimFJ44iAM0/zolcW3AdOekzpJ094layhXNm2lFePCRTXBAUPdghGER05obuLJspqS JiBwZmecXwxSEbcLgfgNdre4eQPwY9mu1X8LBwhY38hDCAG5ekdbHhnq3Kru2aVT8Si9 kyKvRLDJhIDgL4hH2gXgoOmKaTrS5NSD/PqQq7RaETRF/yvWYYcgvpZvdjU6VKUpRxF4 NaPw== X-Gm-Message-State: ALyK8tI6k+8qHNCgZI8R+MYp62htuNzDEnmUKvuZ2EqGjz1s8uC61P4QhZnIF30qlvWlWx3J X-Received: by 10.28.144.133 with SMTP id s127mr5435897wmd.12.1464807107471; Wed, 01 Jun 2016 11:51:47 -0700 (PDT) Received: from xps13.localnet (mtl93-18-78-208-94-3.fbx.proxad.net. [78.208.94.3]) by smtp.gmail.com with ESMTPSA id m7sm36483409wma.10.2016.06.01.11.51.46 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 01 Jun 2016 11:51:46 -0700 (PDT) From: Thomas Monjalon To: "Wiles, Keith" Cc: Yuanhan Liu , dev@dpdk.org, "Richardson, Bruce" , "Tan, Jianfeng" , Stephen Hemminger , Christian Ehrhardt , Panu Matilainen , Olivier Matz Date: Wed, 01 Jun 2016 20:51:45 +0200 Message-ID: <1809080.StTKWmco5F@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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: Wed, 01 Jun 2016 18:51:47 -0000 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