24/01/2019 15:46, Ferruh Yigit: > On 1/24/2019 2:32 PM, Thomas Monjalon wrote: > > 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? > > When patch status updated, they will disappear from our radar, should we do > something to remind us this kind of work needs to be done and already some > patches are available to benefit. > > Keeping them in the patchwork is one option, but it is getting hard to manage > as > the list grows there, and not all work stays relevant/active in the backlog. > Also their status is not clear in the patchwork backlog.
I think we should add an item in the roadmap with a link to this patch.
