From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.mhcomputing.net (master.mhcomputing.net [74.208.228.170]) by dpdk.org (Postfix) with ESMTP id 376AD690F for ; Wed, 1 Jun 2016 17:46:29 +0200 (CEST) Received: by mail.mhcomputing.net (Postfix, from userid 1000) id A428AF8; Wed, 1 Jun 2016 08:46:28 -0700 (PDT) Date: Wed, 1 Jun 2016 08:46:28 -0700 From: Matthew Hall To: "Wiles, Keith" Cc: Yuanhan Liu , Thomas Monjalon , "dev@dpdk.org" , "Richardson, Bruce" , "Tan, Jianfeng" , Stephen Hemminger , Christian Ehrhardt , Panu Matilainen , Olivier Matz Message-ID: <20160601154628.GA5010@mhcomputing.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dpdk-dev] [RFC] Yet another option for DPDK options X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 15:46:29 -0000 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.