[dpdk-dev] [RFC] Yet another option for DPDK options
mhall at mhcomputing.net
Wed Jun 1 17:46:28 CEST 2016
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.
More information about the dev