On 7/13/2017 11:07 AM, kubax.kozak at intel.com (Kuba Kozak) wrote: > This patchset introduce a mechanism for running dpdk application with > parameters provided by configuration file. > > A new API for EAL takes a config file data type - either loaded from > file, or built up programmatically in the application - and extracts > DPDK parameters from it to be used when eal init is called. > This allows apps to have an alternative method to configure EAL, > other than via command-line parameters. > > Reworked applications are used to demonstrate the new eal API. > If a --cfgfile-path <path> option is passed into command line non > EAL section, then the file is loaded and used by app. If a file > called config.ini is present in current working directory, and > no --cfgfile-path option is passed in, config.ini file will be > loaded and used by app. > > Patch "app/testpmd: add parse options from JSON cfg file" > demonstrates the usage of JSON instead of INI file format. > JSON file can be called the same way as above, > through --cfgfile-path <path> argument. > --- > this patch depends on: > "Rework cfgfile API to enable apps config file support" > > v5: > changed define "RTE_DEVTYPE_VIRTUAL" to "RTE_DEVTYPE_UNDEFINED" > due to compilation errors (changes on current master). > > v4: > Code optimalisation in parse_vdev_devices() function. > Moved some functions from librte_eal/bsdapp and librte_eal/linuxapp > to the librte_eal/common. > Bug fixes. > > v3: > split one patchset into two distinct patchsets: > 1. cfgfile library and TEST app changes > 2. EAL changes and examples (this patchset depends on cfgfile) > > v2: > lib eal: > Rework of rte_eal_configure(struct rte_cfgfile *cfg, char *prgname). > Now this function load data from cfg structure and did initial > initialization of EAL arguments. Vdev argument are stored in different > subsections eg. DPDK.vdev0, DPDK.vdev1 etc. After execution of this > function it is necessary to call rte_eal_init to complete EAL > initialization. There is no more merging arguments from different > sources (cfg file and command line). > Added non_eal_configure to testpmd application. > Function maintain the same functionality as rte_eal_configure but > for non-eal arguments. > Added config JSON feature to testpmd last patch from patchset contain > example showing use of .json configuration files. > > lib cfgfile: > Rework of add_section(), add_entry() new implementation > New members allocated_entries/sections, free_entries/sections > in rte_cfgfile structure, change in array of pointers > **sections, **entries instead of *sections[], *entries[] > Add set_entry() to update/overwrite already existing entry in cfgfile > struct > Add save() function to save on disc cfgfile structure in INI format > Rework of existing load() function simplifying the code > Add unit test realloc_sections() in TEST app for testing realloc/malloc > of new API functions, add test for save() function > > Kuba Kozak (3): > eal: add functions parsing EAL arguments > app/testpmd: add parse options from cfg file > app/testpmd: add parse options from JSON cfg file
This patchset is idle more than a year now. It solves problem of eal parameters, it doesn't remove them but at least moves from command line to config file. The patch seems mostly done, but what is the status of it, do we want to continue it? And if we want to continue it can this be a good candidate for GCOS?
