24/01/2019 14:54, Ferruh Yigit: > On 1/23/2019 8:26 PM, Thomas Monjalon wrote: > > 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. > > Is there any actions do we need to take when patches are rejected?
Not sure I understand your question. Any opinion about such plan?
