Re: [RFC] Yet another option for DPDK options

["Wiles, Keith" <keith.wiles@intel.com>]

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.
>