From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f172.google.com (mail-pf0-f172.google.com [209.85.192.172]) by dpdk.org (Postfix) with ESMTP id C73975A7B for ; Wed, 1 Jun 2016 20:31:43 +0200 (CEST) Received: by mail-pf0-f172.google.com with SMTP id f144so19896517pfa.3 for ; Wed, 01 Jun 2016 11:31:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=Z/zlLicocsM5yR9Wt/jk1r8DYIgcWlMAHI6zAG5zuuo=; b=0fxCVOgWvzXK6Nj4zR2xabegoJRRk8BYnutHfXG7WT4pqPszyyy9wsOP0aNarwtxRP 4ekiRVwFmibyk9+01xbm8V2yA4ovenCljBY/7N5BUA+60892S15IkGhK2JpqKMaretEX 6VVsFoyEr5EBHLF0v1zRiIxYQ/QzfkROWXK91WMNAtphiqlGsQXCSo/FnLvLJsR/m4a5 JdQSfk8npfkQ/sNPJFmOJLkarCfQeIz1GZ5QabW3M+WEZflMtOxry//QuDCQUfWRyNtp yjdZejZlyagSruTQG/Fq2IcW5xvUDczP2Ox2/xj8Sug/ez31CJ9uw5ndXlfZjBP/QenJ fUKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Z/zlLicocsM5yR9Wt/jk1r8DYIgcWlMAHI6zAG5zuuo=; b=XN/a5JRWkAhg4zMoBTM5XGgJGfnOiPTkG+GgmwbikSitPI+A4GbXDDKyQALP57fmhL S2wnPAWtNayWfbKEhLIUlp7dDdByKHli00x2PVW3POhoWBvL/diRiLF3H7/xbkRbMkxj HsoFx6EfsX1rxJ59C4VFXcWwvOCyE8IldsKnSnflUoa1HVHevJIk8SESTquctwEvmjCi lUeyK/FAKetOUn5fv+3Aq71/rQWGY/9Yx82MN7xSAspMMlmWv8NBXTywO3WKZQnR6xRL +n59f6eZNTWKbnp3rjvACW86ZIyKO00LXiT+DaPYMg9YfruBmwnY09LiyXiHGc9ryeds PuLg== X-Gm-Message-State: ALyK8tKoVpFm5iuJXPGoZe1St1K1aR7/set+tf+3GPK3MKyzRjbaUE0ggTNxN8y2waBXFQ== X-Received: by 10.98.103.7 with SMTP id b7mr11090528pfc.19.1464805902860; Wed, 01 Jun 2016 11:31:42 -0700 (PDT) Received: from xeon-e3 (static-50-53-72-186.bvtn.or.frontiernet.net. [50.53.72.186]) by smtp.gmail.com with ESMTPSA id b73sm46725246pfd.61.2016.06.01.11.31.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Jun 2016 11:31:42 -0700 (PDT) Date: Wed, 1 Jun 2016 11:31:56 -0700 From: Stephen Hemminger To: Bruce Richardson Cc: Jay Rolette , "Wiles, Keith" , Yuanhan Liu , Thomas Monjalon , "dev@dpdk.org" , "Tan, Jianfeng" , Christian Ehrhardt , Panu Matilainen , Olivier Matz Message-ID: <20160601113156.119dd3fe@xeon-e3> In-Reply-To: <20160601161826.GA9760@bricha3-MOBL3> References: <20160601161826.GA9760@bricha3-MOBL3> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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:31:44 -0000 On Wed, 1 Jun 2016 17:18:26 +0100 Bruce Richardson wrote: > On Wed, Jun 01, 2016 at 10:58:41AM -0500, Jay Rolette wrote: > > On Wed, Jun 1, 2016 at 10:00 AM, Wiles, Keith wrote: > > > > > 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. 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. > > > > > > I have been looking at a number of different options here and the > > > direction I was thinking was using a file for the options and > > > configurations with the data in a clean format. It could have been a INI > > > file or JSON or XML, but they all seem to have some problems I do not like. > > > The INI file is too flat and I wanted a hierarchy in the data, the JSON > > > data is similar and XML is just hard to read. I wanted to be able to manage > > > multiple applications and possible system the DPDK/app runs. The problem > > > with the above formats is they are just data and not easy to make decisions > > > about the system and applications at runtime. > > > > > > > INI format is simplest for users to read, but if you really need hierarchy, > > JSON will do that just fine. Not sure what you mean by "JSON data is > > similar"... > > > > > I'd be quite concerned if we start needing lots of hierarchies for configuration. > > I'd really just like to see ini file format used for this because: > * it's a well understood, simple format > * very easily human readable and editable > * lots of support for it in lots of languages > * hierarchies are possible in it too - just not as easy as in other formats > though. [In a previous life I worked with ini files which had address > hierarchies 6-levels deep in them. It wasn't hard to work with] > * it works well with grep since you must have one value per-line > * it allows comments > * we already have a DPDK library for parsing them > > However, for me the biggest advantage of using something like ini is that it > would force us to keep things simple! Agreed, INI is much easier to deal with than JSON. Also, lets still keep the configuration options to a minimum. And the defaults must still work.