[dpdk-dev] [RFC] Yet another option for DPDK options
e_zhumabekov at sts.kz
Fri Jun 3 12:07:14 CEST 2016
We're using INI in our app, turned out to be quite simple, like this:
;; 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 <keith.wiles at intel.com> wrote:
>>> Started from the link below, but did not want to highjack the thread.
>>> 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
> 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.
More information about the dev