From: "Wiles, Keith" <keith.wiles@intel.com>
To: Matthew Hall <mhall@mhcomputing.net>
Cc: Yuanhan Liu <yuanhan.liu@linux.intel.com>,
Thomas Monjalon <thomas.monjalon@6wind.com>,
"dev@dpdk.org" <dev@dpdk.org>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
"Tan, Jianfeng" <jianfeng.tan@intel.com>,
Stephen Hemminger <stephen@networkplumber.org>,
Christian Ehrhardt <christian.ehrhardt@canonical.com>,
Panu Matilainen <pmatilai@redhat.com>,
Olivier Matz <olivier.matz@6wind.com>
Subject: Re: [dpdk-dev] [RFC] Yet another option for DPDK options
Date: Wed, 1 Jun 2016 16:08:50 +0000 [thread overview]
Message-ID: <04DCF65E-E97A-4CC0-B9BA-F63347214C3F@intel.com> (raw)
In-Reply-To: <20160601154628.GA5010@mhcomputing.net>
Regards,
Keith
On 6/1/16, 10:46 AM, "Matthew Hall" <mhall@mhcomputing.net> wrote:
>On Wed, Jun 01, 2016 at 03:00:11PM +0000, Wiles, Keith wrote:
>> 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 don't think it's fair to say JSON lacks hierarchy. Personally it is working
>great in my current application. The main "bug" is that the spec designers
>intentionally and idiotically left out the ability to make comments. But there
>are some smarter JSON parsers such as json-c and the Perl JSON parser which
>will allow them using either "#" or "//".
JSON-C could work and Lua has its comments too. I just wanted more from the configuration then just data. You still need some code to parse the JSON format in the application, right?
>
>You can also build JSON in memory pretty nicely using json-c. It has a simple
>DOM-like API for this.
>
>I am using it in the config file for my app right now, and passing a fake argc
>and argv to DPDK using wordexp() to prevent it from munging the argc and argv
>of my application.
>
>> It would be nice to execute a DPDK applications like this:
>>
>> ./some_dpdk_app ???config-file dpdk-config-filename
>
>FYI, I think you used Outlook with some of MS's bad defaults and it mangled
>all your special characters...
Yes, I hate MS Outlook. I have tried to fix the options, but it never seems to work out. Until someone create a really good email application for OS X that works with exchange I will stuck with this one. I have tried a number of different ones, they all have limitations or problems ☹
>
>> The dpdk-config-filename could contain a lot of information and be able to
>> startup multiple different applications. The dpdk-config-file could also
>> include other config files to complete the configuration. The format of the
>> data in the config file needs to be readable, but allow the user to put in
>> new options, needs to be hierarchical in nature and have some simple
>> functions to execute if required.
>
>To me, this is way too complicated and includes a lot of features I'm not
>convinced we actually need or want. I'd really prefer if we just have one file
>per app. I don't want a super complicated way to configure it replacing an
>already super complicated way to configure it.
I do not see it being too complexed I think it is what you have used before and not that it is to complex of a solution.
>
>> The solution I was thinking is the file information is really just a
>> fragment of a scripting language, which the DPDK application contains this
>> scripting language interpreter. I was looking at using Lua lua.org as the
>> scripting language interpreter it is small and easy to understand.
>
>If we're stuck doing this Lua is the best option but I'd still rather avoid
>it. I like the fact that DPDK is a lot of clean C code, this is why I find it
>so much easier to read and code than the awful kernel network stacks.
We do not need to understand Lua interpreter or compiler only the simple Lua scripting code.
>
>> lcore_list = mk_lcore_list("0-7", 10, "14-16"),
>> coremap = mk_coremap("(0-7)@0,10,(14-16)@1"),
>
>These magical functions feel weird compared to just having some simple
>functions that take them as JSON strings and validate them. Which is what I'm
>doing in my app right now with minimal pain.
These are just examples to convert to tables from strings and could have not used them.
>
>> The EAL, driver, application, ??? would query an API to access the data and
>> the application can change his options quickly without modifying the code.
>
>I don't want to have to use somebody else's API to get to the config of my app
>if I can avoid it. I like the approach of json-c where I can lay it out how I
>want, and pass the parts I want DPDK to have over to DPDK. I don't necessarily
>want to have to go through DPDK to get to my own config stuff. Which is what I
>am stuck doing if we put a weird proprietary DPDK specific file format or
>scripting environment in these files.
Not sure the meaning of someone else’s API, we already have a difficult configuration structure and command line interface, just trying to create a common set up database like APIs to access the data. Now maybe JSON-c has some already I do not know. Removing the command line options for just one option ☺ seems like a good thing.
>
>> Keith
>
>Matthew.
>
next prev parent reply other threads:[~2016-06-01 16:09 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-01 15:00 Wiles, Keith
2016-06-01 15:46 ` Matthew Hall
2016-06-01 16:08 ` Wiles, Keith [this message]
2016-06-01 15:58 ` Jay Rolette
2016-06-01 16:18 ` Bruce Richardson
2016-06-01 16:21 ` Arnon Warshavsky
2016-06-01 18:13 ` Wiles, Keith
2016-06-01 18:31 ` Stephen Hemminger
2016-06-03 10:07 ` Yerden Zhumabekov
2016-06-01 18:51 ` Thomas Monjalon
2016-06-02 9:19 ` Marc
2016-06-02 7:56 ` Yuanhan Liu
2016-06-02 10:41 ` Neil Horman
2016-06-02 13:19 ` Thomas Monjalon
2016-06-02 13:53 ` Wiles, Keith
2016-06-02 17:11 ` Neil Horman
2016-06-02 19:33 ` Wiles, Keith
2016-06-02 19:41 ` Wiles, Keith
2016-06-02 20:08 ` Neil Horman
2016-06-02 20:53 ` Matthew Hall
2016-06-02 22:34 ` Neil Horman
2016-06-03 2:17 ` Matthew Hall
2016-06-03 9:57 ` Bruce Richardson
2016-06-03 10:06 ` Bruce Richardson
2016-06-03 12:03 ` Neil Horman
2016-06-03 10:29 ` Bruce Richardson
2016-06-03 11:01 ` Bruce Richardson
2016-06-03 11:50 ` Neil Horman
2016-06-03 12:01 ` Arnon Warshavsky
2016-06-03 12:53 ` Panu Matilainen
2016-06-03 14:31 ` Arnon Warshavsky
2016-06-03 16:04 ` Wiles, Keith
2016-06-03 16:10 ` Wiles, Keith
2016-06-03 17:44 ` Neil Horman
2016-06-03 18:29 ` Wiles, Keith
2016-06-03 18:38 ` Neil Horman
2016-06-03 18:52 ` Arnon Warshavsky
2016-06-03 19:00 ` Wiles, Keith
2016-06-03 19:07 ` Wiles, Keith
2016-06-03 19:18 ` Neil Horman
2016-06-03 19:23 ` Wiles, Keith
2016-06-03 19:28 ` Arnon Warshavsky
2016-06-03 21:42 ` Matthew Hall
2016-06-03 21:41 ` Matthew Hall
2016-06-05 0:19 ` Neil Horman
2016-06-03 21:40 ` Matthew Hall
2016-06-03 21:38 ` Matthew Hall
2016-06-03 12:14 ` Panu Matilainen
2016-06-02 20:51 ` Matthew Hall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=04DCF65E-E97A-4CC0-B9BA-F63347214C3F@intel.com \
--to=keith.wiles@intel.com \
--cc=bruce.richardson@intel.com \
--cc=christian.ehrhardt@canonical.com \
--cc=dev@dpdk.org \
--cc=jianfeng.tan@intel.com \
--cc=mhall@mhcomputing.net \
--cc=olivier.matz@6wind.com \
--cc=pmatilai@redhat.com \
--cc=stephen@networkplumber.org \
--cc=thomas.monjalon@6wind.com \
--cc=yuanhan.liu@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).