Re: [RFC] Yet another option for DPDK options

[Matthew Hall <mhall@mhcomputing.net>]

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

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

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

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

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

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

> Keith

Matthew.