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.
