From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com [209.85.218.45]) by dpdk.org (Postfix) with ESMTP id C528C68F5 for ; Wed, 1 Jun 2016 18:21:13 +0200 (CEST) Received: by mail-oi0-f45.google.com with SMTP id e72so35516345oib.1 for ; Wed, 01 Jun 2016 09:21:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qwilt-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Y9Fv86v0frsGvWbK8sjP8el+zOYjmsASGsIJb4hk24o=; b=sNs0KBts5QsV8HABD9EkqRoQ4PzGyMxKwb/y9f/d8YjW8Vlg4Ynim6jMaEOJAnpRbc hrgfHe21lJxKkWzdt8rpgHKOvGefn3UKqVUllUV061h5wy9fz8bQk7vCnr2BIKvWy8aF KAm7EocHqmUs8BUVZt4sGq/vlfKb+cAyiUUBY0YcE6MCZmtNOsZAkMVvqK9Zr1FZocLp QZjrve0yj4F+9T8UmXbSqVQf9jTzEvBb8y3OVtdYF6KC8+ghoPpG71s0XDYSoZW+rOVA 8pTYcj4iBe8vTa71SrbJAeFU7HUEE6H+gEQYtmU8aYQ1tnc3Tsu0RTWgo1JH5+bytFtT jtMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Y9Fv86v0frsGvWbK8sjP8el+zOYjmsASGsIJb4hk24o=; b=l0aE3cza+wAN7U270iGtCISlpnrRVuNj5KDbutznDIOyXgOLnSZ9CBuMMYmPEN0sWN RMKUOoye5z6q7Yl0tpwstp2RPCuWPceeDZq6MG/PN/o7BXWsSanXIjpnFeXH1NeNcD/s SIit8/5Ul8GaO0uaQ4I2lUqh/cdtfhJUZVHv8HcTkU7ZV3r6XRjrEatP1cQn8ekTdeqi uNogOxXtVNJC4HHmrJDO2mOnBYDCVZaFD7ZatP2aeHOZil1lzVi2+0CSVJVnRse3RQgd giCOV7lyZwA3eFlSZva/AG1fexvkY4V1xIz2RXkAT2yWzkEA+SEU7Y4HhBkPqWTV0Vkm CjjQ== X-Gm-Message-State: ALyK8tL1TOtnO7qjyprC+ZFkJ8H9rNiFSZ7cKT21EWF3C9UBdQWlkB7dAZoM/Bvy2OEKa1PnDWE9wddL/NCZVQ== MIME-Version: 1.0 X-Received: by 10.202.253.83 with SMTP id b80mr21372317oii.198.1464798073115; Wed, 01 Jun 2016 09:21:13 -0700 (PDT) Received: by 10.182.108.37 with HTTP; Wed, 1 Jun 2016 09:21:13 -0700 (PDT) In-Reply-To: <20160601161826.GA9760@bricha3-MOBL3> References: <20160601161826.GA9760@bricha3-MOBL3> Date: Wed, 1 Jun 2016 19:21:13 +0300 Message-ID: From: Arnon Warshavsky To: Bruce Richardson Cc: Jay Rolette , "Wiles, Keith" , Yuanhan Liu , Thomas Monjalon , "dev@dpdk.org" , "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: Wed, 01 Jun 2016 16:21:14 -0000 On Wed, Jun 1, 2016 at 7:18 PM, 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! > > I'd stay away from formats like json or XML that are designed for > serializing > entire objects or structures, and look for something that allows us to just > specify configuration values. > > Regards, > /Bruce > > +1 for a single cfg file parameter +1 for ini simplicity /Arnon