23/01/2019 20:31, Ferruh Yigit: > 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?
I think we must focus on reorganization of EAL first. When the options parsing will be better isolated, and accessible from API independant of rte_eal_init, then we could provide some helpers to use those APIs for a config file, a custom command line or anything else.