24/01/2019 14:54, Ferruh Yigit:

On 1/23/2019 8:26 PM, Thomas Monjalon wrote:

quoted

23/01/2019 20:31, Ferruh Yigit:

quoted

On 7/13/2017 11:07 AM, kubax.kozak at intel.com (Kuba Kozak) wrote:

quoted

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?