From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mgw.gov.kz (mgw.gov.kz [178.89.4.254]) by dpdk.org (Postfix) with ESMTP id 22EAB592F for ; Fri, 3 Jun 2016 12:07:16 +0200 (CEST) Received: from sts.kz (mail.sts.kz [178.89.4.9]) by mgw.gov.kz with ESMTP id u53A7FRo017885-u53A7FRq017885 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Jun 2016 16:07:15 +0600 Received: from [172.20.19.232] (unknown [178.89.4.11]) by sts.kz (Postfix) with ESMTPA id 29EAF65C0; Fri, 3 Jun 2016 16:07:14 +0600 (ALMT) DKIM-Filter: OpenDKIM Filter v2.10.3 sts.kz 29EAF65C0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sts.kz; s=mail; t=1464948435; bh=7JPWcNJqC8HnDeFFU7MI400O9Ca63aDcad3tWBrXdxU=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=BkX0G18+usOs9+BzZlYU92TZFFIPq1V277RSYEyPqZn/7qC5f1Q4tY1SocqTEzu7G HlICAW93PYNJ3e5XZxd7Zn7wk9ITKjBv3CJKQbsPqP7q7loV9GUUTkAp94Ukzjb9Rh 0vY2RVDq3RIeT5nBzMUgjRn75UzH9+z3k6+/patE= To: dev@dpdk.org References: <20160601161826.GA9760@bricha3-MOBL3> Cc: bruce.richardson@intel.com From: Yerden Zhumabekov Message-ID: <575156D2.8040800@sts.kz> Date: Fri, 3 Jun 2016 16:07:14 +0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160601161826.GA9760@bricha3-MOBL3> Content-Type: text/plain; charset=windows-1252; format=flowed 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: Fri, 03 Jun 2016 10:07:16 -0000 +1 We're using INI in our app, turned out to be quite simple, like this: [eal] ;; EAL common options: ;; -c COREMASK Hexadecimal bitmask of cores to run on # coremask = fff ;; -l CORELIST List of cores to run on corelist = 3,4,5 ;; --lcores COREMAP Map lcore set to physical cpu set ; coremap = ;; --master-lcore ID Core ID that is used as master ; master-lcore-id = 0 ;; -n CHANNELS Number of memory channels memory-channels = 4 On 01.06.2016 22:18, 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 >