On 1/24/2019 4:06 PM, Thomas Monjalon wrote: > 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.
OK. Do you want me do it?
