24/01/2019 17:18, Ferruh Yigit: > 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?
Yes please expose your view in a roadmap patch. If needed, we can discuss the plan in techboard meeting.
