[dpdk-dev,v4,1/3] eal: add functions parsing EAL arguments
Checks
Commit Message
added function rte_eal_configure which configure
Environment Abstraction Layer (EAL) using
configuration structure.
Signed-off-by: Kuba Kozak <kubax.kozak@intel.com>
Suggested-by: Bruce Richardson <bruce.richardson@intel.com>
---
lib/Makefile | 3 +
lib/librte_eal/bsdapp/eal/Makefile | 4 +
lib/librte_eal/bsdapp/eal/eal.c | 165 +++++++++++----
lib/librte_eal/bsdapp/eal/rte_eal_version.map | 1 +
lib/librte_eal/common/eal_common_lcore.c | 7 +
lib/librte_eal/common/eal_common_options.c | 106 ++++++++++
lib/librte_eal/common/eal_options.h | 3 +
lib/librte_eal/common/include/rte_eal.h | 20 ++
lib/librte_eal/linuxapp/eal/Makefile | 3 +
lib/librte_eal/linuxapp/eal/eal.c | 265 ++++++++++++++++--------
lib/librte_eal/linuxapp/eal/rte_eal_version.map | 1 +
mk/rte.app.mk | 2 +-
12 files changed, 452 insertions(+), 128 deletions(-)
Comments
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
app/test-pmd/Makefile | 6 +
app/test-pmd/config.ini | 24 +
app/test-pmd/config.json | 33 +
app/test-pmd/parameters.c | 1181 +++++++++++++----------
app/test-pmd/testpmd.c | 159 ++-
app/test-pmd/testpmd.h | 3 +-
config/common_base | 5 +
lib/Makefile | 3 +
lib/librte_eal/bsdapp/eal/Makefile | 4 +
lib/librte_eal/bsdapp/eal/eal.c | 165 +++-
lib/librte_eal/bsdapp/eal/rte_eal_version.map | 1 +
lib/librte_eal/common/eal_common_lcore.c | 7 +
lib/librte_eal/common/eal_common_options.c | 106 ++
lib/librte_eal/common/eal_options.h | 3 +
lib/librte_eal/common/include/rte_eal.h | 20 +
lib/librte_eal/linuxapp/eal/Makefile | 3 +
lib/librte_eal/linuxapp/eal/eal.c | 265 +++--
lib/librte_eal/linuxapp/eal/rte_eal_version.map | 1 +
mk/rte.app.mk | 2 +-
19 files changed, 1349 insertions(+), 642 deletions(-)
create mode 100644 app/test-pmd/config.ini
create mode 100644 app/test-pmd/config.json
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
app/test-pmd/Makefile | 6 +
app/test-pmd/config.ini | 24 +
app/test-pmd/config.json | 33 +
app/test-pmd/parameters.c | 1181 +++++++++++++----------
app/test-pmd/testpmd.c | 159 ++-
app/test-pmd/testpmd.h | 3 +-
config/common_base | 5 +
lib/Makefile | 3 +
lib/librte_eal/bsdapp/eal/Makefile | 4 +
lib/librte_eal/bsdapp/eal/eal.c | 165 +++-
lib/librte_eal/bsdapp/eal/rte_eal_version.map | 1 +
lib/librte_eal/common/eal_common_lcore.c | 7 +
lib/librte_eal/common/eal_common_options.c | 106 ++
lib/librte_eal/common/eal_options.h | 3 +
lib/librte_eal/common/include/rte_eal.h | 20 +
lib/librte_eal/linuxapp/eal/Makefile | 3 +
lib/librte_eal/linuxapp/eal/eal.c | 265 +++--
lib/librte_eal/linuxapp/eal/rte_eal_version.map | 1 +
mk/rte.app.mk | 2 +-
19 files changed, 1349 insertions(+), 642 deletions(-)
create mode 100644 app/test-pmd/config.ini
create mode 100644 app/test-pmd/config.json
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?
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.
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?
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?
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.
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.
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?
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.
On 1/24/2019 5:45 PM, Thomas Monjalon wrote:
> 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.
sent, https://mails.dpdk.org/archives/web/2019-January/001011.html
@@ -34,6 +34,9 @@ include $(RTE_SDK)/mk/rte.vars.mk
DIRS-y += librte_compat
DIRS-$(CONFIG_RTE_LIBRTE_CFGFILE) += librte_cfgfile
DIRS-$(CONFIG_RTE_LIBRTE_EAL) += librte_eal
+ifeq ($(CONFIG_RTE_LIBRTE_CFGFILE),y)
+DEPDIRS-librte_eal := librte_cfgfile
+endif
DIRS-$(CONFIG_RTE_LIBRTE_RING) += librte_ring
DEPDIRS-librte_ring := librte_eal
DIRS-$(CONFIG_RTE_LIBRTE_MEMPOOL) += librte_mempool
@@ -50,6 +50,10 @@ EXPORT_MAP := rte_eal_version.map
LIBABIVER := 4
+ifeq ($(CONFIG_RTE_LIBRTE_CFGFILE),y)
+LDLIBS += -lrte_cfgfile
+endif
+
# specific to bsdapp exec-env
SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) := eal.c
SRCS-$(CONFIG_RTE_EXEC_ENV_BSDAPP) += eal_memory.c
@@ -73,6 +73,7 @@
#include <rte_version.h>
#include <rte_atomic.h>
#include <malloc_heap.h>
+#include <rte_cfgfile.h>
#include "eal_private.h"
#include "eal_thread.h"
@@ -99,6 +100,8 @@ static struct flock wr_lock = {
.l_len = sizeof(early_mem_config.memseg),
};
+static int run_once_reset_internal_config;
+
/* Address of global and public configuration */
static struct rte_config rte_config = {
.mem_config = &early_mem_config,
@@ -347,6 +350,58 @@ eal_log_level_parse(int argc, char **argv)
optarg = old_optarg;
}
+/* Parse single argument */
+static int
+eal_parse_option(int opt, char *optarg, int option_index, char *prgname)
+{
+ int ret;
+
+ /* getopt is not happy, stop right now */
+ if (opt == '?') {
+ eal_usage(prgname);
+ ret = -1;
+ goto out;
+ }
+
+ ret = eal_parse_common_option(opt, optarg, &internal_config);
+ /* common parser is not happy */
+ if (ret < 0) {
+ eal_usage(prgname);
+ ret = -1;
+ goto out;
+ }
+ /* common parser handled this option */
+ if (ret == 0)
+ return 0;
+
+ switch (opt) {
+ case 'h':
+ eal_usage(prgname);
+ exit(EXIT_SUCCESS);
+ break;
+
+ default:
+ if (opt < OPT_LONG_MIN_NUM && isprint(opt)) {
+ RTE_LOG(ERR, EAL, "Option %c is not supported "
+ "on FreeBSD\n", opt);
+ } else if (opt >= OPT_LONG_MIN_NUM &&
+ opt < OPT_LONG_MAX_NUM) {
+ RTE_LOG(ERR, EAL, "Option %s is not supported "
+ "on FreeBSD\n",
+ eal_long_options[option_index].name);
+ } else {
+ RTE_LOG(ERR, EAL, "Option %d is not supported "
+ "on FreeBSD\n", opt);
+ }
+ eal_usage(prgname);
+ ret = -1;
+ goto out;
+ }
+ return 0;
+out:
+ return ret;
+}
+
/* Parse the argument given in the command line of the application */
static int
eal_parse_args(int argc, char **argv)
@@ -367,45 +422,9 @@ eal_parse_args(int argc, char **argv)
while ((opt = getopt_long(argc, argvopt, eal_short_options,
eal_long_options, &option_index)) != EOF) {
- /* getopt is not happy, stop right now */
- if (opt == '?') {
- eal_usage(prgname);
- ret = -1;
- goto out;
- }
-
- ret = eal_parse_common_option(opt, optarg, &internal_config);
- /* common parser is not happy */
- if (ret < 0) {
- eal_usage(prgname);
- ret = -1;
- goto out;
- }
- /* common parser handled this option */
- if (ret == 0)
- continue;
-
- switch (opt) {
- case 'h':
- eal_usage(prgname);
- exit(EXIT_SUCCESS);
- default:
- if (opt < OPT_LONG_MIN_NUM && isprint(opt)) {
- RTE_LOG(ERR, EAL, "Option %c is not supported "
- "on FreeBSD\n", opt);
- } else if (opt >= OPT_LONG_MIN_NUM &&
- opt < OPT_LONG_MAX_NUM) {
- RTE_LOG(ERR, EAL, "Option %s is not supported "
- "on FreeBSD\n",
- eal_long_options[option_index].name);
- } else {
- RTE_LOG(ERR, EAL, "Option %d is not supported "
- "on FreeBSD\n", opt);
- }
- eal_usage(prgname);
- ret = -1;
+ ret = eal_parse_option(opt, optarg, option_index, prgname);
+ if (ret < 0)
goto out;
- }
}
if (eal_adjust_config(&internal_config) != 0) {
@@ -517,7 +536,10 @@ rte_eal_init(int argc, char **argv)
thread_id = pthread_self();
- eal_reset_internal_config(&internal_config);
+ if (!run_once_reset_internal_config) {
+ eal_reset_internal_config(&internal_config);
+ run_once_reset_internal_config = 1;
+ }
/* set log level as early as possible */
eal_log_level_parse(argc, argv);
@@ -677,3 +699,68 @@ rte_eal_process_type(void)
{
return rte_config.process_type;
}
+
+#ifdef RTE_LIBRTE_CFGFILE
+int
+rte_eal_configure(struct rte_cfgfile *cfg, char *prgname)
+{
+ int n_entries;
+ int i;
+ int opt;
+ int option_index;
+
+ if (cfg == NULL) {
+ rte_errno = -EINVAL;
+ return -1;
+ }
+
+ n_entries = rte_cfgfile_section_num_entries(cfg, "DPDK");
+
+ if (n_entries < 1) {
+ printf("No DPDK section entries in cfgfile object\n");
+ return 0;
+ }
+
+ struct rte_cfgfile_entry entries[n_entries];
+
+ if (n_entries !=
+ rte_cfgfile_section_entries(cfg, "DPDK", entries,
+ n_entries)) {
+ rte_eal_init_alert("Unexpected fault.");
+ rte_errno = EFAULT;
+ return -1;
+ }
+
+ if (!run_once_reset_internal_config) {
+ eal_reset_internal_config(&internal_config);
+ run_once_reset_internal_config = 1;
+ }
+
+ /* set log level as early as possible */
+ eal_log_level_cfg(cfg);
+
+ if (rte_eal_cpu_init() < 0) {
+ rte_eal_init_alert("Cannot detect lcores.");
+ rte_errno = ENOTSUP;
+ return -1;
+ }
+
+ for (i = 0; i < n_entries; i++) {
+ eal_getopt(entries[i].name, &opt, &option_index);
+
+ if (eal_parse_option(opt, entries[i].value,
+ option_index, prgname) != 0) {
+ rte_eal_init_alert("Invalid config file arguments.");
+ rte_errno = EINVAL;
+ return -1;
+ }
+ }
+
+ if (parse_vdev_devices(cfg) < 0) {
+ rte_eal_init_alert("Couldn't parse vdevs");
+ rte_errno = ENOMEM;
+ return -1;
+ }
+ return 0;
+}
+#endif
@@ -200,6 +200,7 @@ DPDK_17.08 {
rte_bus_find;
rte_bus_find_by_device;
rte_bus_find_by_name;
+ rte_eal_configure;
} DPDK_17.05;
@@ -53,11 +53,18 @@
int
rte_eal_cpu_init(void)
{
+ static int run_once;
+ static int ret;
/* pointer to global configuration */
struct rte_config *config = rte_eal_get_configuration();
unsigned lcore_id;
unsigned count = 0;
+ /* No need to calculate this function again if we know the result */
+ if (run_once)
+ return ret;
+ run_once = 1;
+
/*
* Parse the maximum set of logical cores, detect the subset of running
* ones and enable them by default.
@@ -50,6 +50,10 @@
#include <rte_version.h>
#include <rte_devargs.h>
#include <rte_memcpy.h>
+#ifdef RTE_LIBRTE_CFGFILE
+#include <rte_cfgfile.h>
+#include <rte_errno.h>
+#endif
#include "eal_internal_cfg.h"
#include "eal_options.h"
@@ -1078,3 +1082,105 @@ eal_common_usage(void)
" --"OPT_NO_SHCONF" No shared config (mmap'd files)\n"
"\n", RTE_MAX_LCORE);
}
+
+#ifdef RTE_LIBRTE_CFGFILE
+/* Parse the arguments for --log-level only */
+void
+eal_log_level_cfg(struct rte_cfgfile *cfg)
+{
+ const char *entry;
+
+ entry = rte_cfgfile_get_entry(cfg, "DPDK", OPT_LOG_LEVEL);
+ if (entry)
+ eal_parse_common_option(OPT_LOG_LEVEL_NUM, entry,
+ &internal_config);
+}
+#endif
+
+#ifdef RTE_LIBRTE_CFGFILE
+static void rte_eal_init_alert(const char *msg)
+{
+ fprintf(stderr, "EAL: FATAL: %s\n", msg);
+ RTE_LOG(ERR, EAL, "%s\n", msg);
+}
+
+#define vdev_buff_size 200
+#define sectionname_size 20
+int
+parse_vdev_devices(struct rte_cfgfile *cfg)
+{
+ char sectionname[sectionname_size] = "DPDK.vdev0";
+ char buffer[vdev_buff_size];
+ int vdev_nb = 0;
+ int n_entries;
+ int buf_len;
+ char *buf_ptr;
+ int i;
+ int ret;
+
+ /* ----------- parsing VDEVS */
+ for (vdev_nb = 1; rte_cfgfile_has_section(cfg, sectionname);
+ vdev_nb++) {
+ n_entries = rte_cfgfile_section_num_entries(cfg, sectionname);
+
+ struct rte_cfgfile_entry entries[n_entries];
+
+ if (n_entries != rte_cfgfile_section_entries(cfg, sectionname,
+ entries, n_entries)) {
+ rte_eal_init_alert("Unexpected fault.");
+ rte_errno = EFAULT;
+ return -1;
+ }
+
+ buffer[0] = '\0';
+ buf_ptr = buffer;
+ buf_len = vdev_buff_size;
+ for (i = 0; i < n_entries; i++) {
+ ret = snprintf(buf_ptr, buf_len, "%s%s%s%s",
+ entries[i].name,
+ (entries[i].value[0] != '\0') ?
+ "=" : "",
+ entries[i].value,
+ (i < (n_entries - 1)) ? "," : "");
+ if (ret >= buf_len) {
+ printf("parse_vdev_devices(): buffer[] size is "
+ "to small\n");
+ return -1;
+ }
+ buf_len -= ret;
+ buf_ptr += ret;
+ }
+
+ /* parsing vdev */
+ if (rte_eal_devargs_add(RTE_DEVTYPE_VIRTUAL,
+ buffer) < 0) {
+ return -1;
+ }
+ snprintf(sectionname, sectionname_size, "DPDK.vdev%d", vdev_nb);
+ }
+ /* ----------- parsing VDEVS */
+ return 0;
+}
+
+void
+eal_getopt(const char *str, int *opt, int *option_index)
+{
+ int i;
+
+ *opt = '?';
+ *option_index = 0;
+
+ if (strlen(str) == 1) {
+ *opt = *str;
+ return;
+ }
+
+ for (i = 0; eal_long_options[i].name != NULL; i++) {
+ if (strcmp(str, eal_long_options[i].name) == 0) {
+ *opt = eal_long_options[i].val;
+ *option_index = i;
+ break;
+ }
+ }
+}
+#endif
@@ -96,5 +96,8 @@ int eal_check_common_options(struct internal_config *internal_cfg);
void eal_common_usage(void);
enum rte_proc_type_t eal_proc_type_detect(void);
int eal_plugins_init(void);
+void eal_log_level_cfg(struct rte_cfgfile *cfg);
+int parse_vdev_devices(struct rte_cfgfile *cfg);
+void eal_getopt(const char *str, int *opt, int *option_index);
#endif /* EAL_OPTIONS_H */
@@ -46,6 +46,8 @@
#include <rte_per_lcore.h>
#include <rte_config.h>
+struct rte_cfgfile; /* forward declaration of struct */
+
#ifdef __cplusplus
extern "C" {
#endif
@@ -188,6 +190,24 @@ int rte_eal_iopl_init(void);
*/
int rte_eal_init(int argc, char **argv);
+#ifdef RTE_LIBRTE_CFGFILE
+/**
+ * Initialize the Environment Abstraction Layer (EAL) using
+ * configuration structure
+ *
+ * @param cfg
+ * pointer to config file structure.
+ * @param prgname
+ * pointer to string with execution path
+ *
+ * @return
+ * - On success, return 0
+ * - On failure, returns -1.
+ */
+int
+rte_eal_configure(struct rte_cfgfile *cfg, char *prgname);
+#endif
+
/**
* Check if a primary process is currently alive
*
@@ -53,6 +53,9 @@ LDLIBS += -lrt
ifeq ($(CONFIG_RTE_EAL_NUMA_AWARE_HUGEPAGES),y)
LDLIBS += -lnuma
endif
+ifeq ($(CONFIG_RTE_LIBRTE_CFGFILE),y)
+LDLIBS += -lrte_cfgfile
+endif
# specific to linuxapp exec-env
SRCS-$(CONFIG_RTE_EXEC_ENV_LINUXAPP) := eal.c
@@ -78,6 +78,9 @@
#include <rte_version.h>
#include <rte_atomic.h>
#include <malloc_heap.h>
+#ifdef RTE_LIBRTE_CFGFILE
+#include <rte_cfgfile.h>
+#endif
#include "eal_private.h"
#include "eal_thread.h"
@@ -101,6 +104,8 @@ static struct rte_mem_config early_mem_config;
* duration of the program, as we hold a write lock on it in the primary proc */
static int mem_cfg_fd = -1;
+static int run_once_reset_internal_config;
+
static struct flock wr_lock = {
.l_type = F_WRLCK,
.l_whence = SEEK_SET,
@@ -515,119 +520,135 @@ eal_log_level_parse(int argc, char **argv)
optarg = old_optarg;
}
-/* Parse the argument given in the command line of the application */
+/* Parse single argument */
static int
-eal_parse_args(int argc, char **argv)
+eal_parse_option(int opt, char *optarg, int option_index, char *prgname)
{
- int opt, ret;
- char **argvopt;
- int option_index;
- char *prgname = argv[0];
- const int old_optind = optind;
- const int old_optopt = optopt;
- char * const old_optarg = optarg;
+ int ret;
- argvopt = argv;
- optind = 1;
+ /* getopt is not happy, stop right now */
+ if (opt == '?') {
+ eal_usage(prgname);
+ ret = -1;
+ goto out;
+ }
- while ((opt = getopt_long(argc, argvopt, eal_short_options,
- eal_long_options, &option_index)) != EOF) {
+ ret = eal_parse_common_option(opt, optarg, &internal_config);
+ /* common parser is not happy */
+ if (ret < 0) {
+ eal_usage(prgname);
+ ret = -1;
+ goto out;
+ }
+ /* common parser handled this option */
+ if (ret == 0)
+ return 0;
- /* getopt is not happy, stop right now */
- if (opt == '?') {
+ switch (opt) {
+ case 'h':
+ eal_usage(prgname);
+ exit(EXIT_SUCCESS);
+ break;
+
+ /* long options */
+ case OPT_XEN_DOM0_NUM:
+#ifdef RTE_LIBRTE_XEN_DOM0
+ internal_config.xen_dom0_support = 1;
+ break;
+#else
+ RTE_LOG(ERR, EAL, "Can't support DPDK app "
+ "running on Dom0, please configure"
+ " RTE_LIBRTE_XEN_DOM0=y\n");
+ ret = -1;
+ goto out;
+#endif
+
+ case OPT_HUGE_DIR_NUM:
+ internal_config.hugepage_dir = optarg;
+ break;
+
+ case OPT_FILE_PREFIX_NUM:
+ internal_config.hugefile_prefix = optarg;
+ break;
+
+ case OPT_SOCKET_MEM_NUM:
+ if (eal_parse_socket_mem(optarg) < 0) {
+ RTE_LOG(ERR, EAL, "invalid parameters for --"
+ OPT_SOCKET_MEM "\n");
eal_usage(prgname);
ret = -1;
goto out;
}
+ break;
- ret = eal_parse_common_option(opt, optarg, &internal_config);
- /* common parser is not happy */
- if (ret < 0) {
+ case OPT_BASE_VIRTADDR_NUM:
+ if (eal_parse_base_virtaddr(optarg) < 0) {
+ RTE_LOG(ERR, EAL, "invalid parameter for --"
+ OPT_BASE_VIRTADDR "\n");
eal_usage(prgname);
ret = -1;
goto out;
}
- /* common parser handled this option */
- if (ret == 0)
- continue;
+ break;
- switch (opt) {
- case 'h':
+ case OPT_VFIO_INTR_NUM:
+ if (eal_parse_vfio_intr(optarg) < 0) {
+ RTE_LOG(ERR, EAL, "invalid parameters for --"
+ OPT_VFIO_INTR "\n");
eal_usage(prgname);
- exit(EXIT_SUCCESS);
-
- /* long options */
- case OPT_XEN_DOM0_NUM:
-#ifdef RTE_LIBRTE_XEN_DOM0
- internal_config.xen_dom0_support = 1;
-#else
- RTE_LOG(ERR, EAL, "Can't support DPDK app "
- "running on Dom0, please configure"
- " RTE_LIBRTE_XEN_DOM0=y\n");
ret = -1;
goto out;
-#endif
- break;
+ }
+ break;
- case OPT_HUGE_DIR_NUM:
- internal_config.hugepage_dir = optarg;
- break;
+ case OPT_CREATE_UIO_DEV_NUM:
+ internal_config.create_uio_dev = 1;
+ break;
- case OPT_FILE_PREFIX_NUM:
- internal_config.hugefile_prefix = optarg;
- break;
+ default:
+ if (opt < OPT_LONG_MIN_NUM && isprint(opt)) {
+ RTE_LOG(ERR, EAL, "Option %c is not supported "
+ "on Linux\n", opt);
+ } else if (opt >= OPT_LONG_MIN_NUM &&
+ opt < OPT_LONG_MAX_NUM) {
+ RTE_LOG(ERR, EAL, "Option %s is not supported "
+ "on Linux\n",
+ eal_long_options[option_index].name);
+ } else {
+ RTE_LOG(ERR, EAL, "Option %d is not supported "
+ "on Linux\n", opt);
+ }
+ eal_usage(prgname);
+ ret = -1;
+ goto out;
+ }
- case OPT_SOCKET_MEM_NUM:
- if (eal_parse_socket_mem(optarg) < 0) {
- RTE_LOG(ERR, EAL, "invalid parameters for --"
- OPT_SOCKET_MEM "\n");
- eal_usage(prgname);
- ret = -1;
- goto out;
- }
- break;
+ return 0;
+out:
+ return ret;
+}
- case OPT_BASE_VIRTADDR_NUM:
- if (eal_parse_base_virtaddr(optarg) < 0) {
- RTE_LOG(ERR, EAL, "invalid parameter for --"
- OPT_BASE_VIRTADDR "\n");
- eal_usage(prgname);
- ret = -1;
- goto out;
- }
- break;
+/* Parse the argument given in the command line of the application */
+static int
+eal_parse_args(int argc, char **argv)
+{
+ int opt, ret;
+ char **argvopt;
+ int option_index;
+ char *prgname = argv[0];
+ const int old_optind = optind;
+ const int old_optopt = optopt;
+ char * const old_optarg = optarg;
- case OPT_VFIO_INTR_NUM:
- if (eal_parse_vfio_intr(optarg) < 0) {
- RTE_LOG(ERR, EAL, "invalid parameters for --"
- OPT_VFIO_INTR "\n");
- eal_usage(prgname);
- ret = -1;
- goto out;
- }
- break;
+ argvopt = argv;
+ optind = 1;
- case OPT_CREATE_UIO_DEV_NUM:
- internal_config.create_uio_dev = 1;
- break;
+ while ((opt = getopt_long(argc, argvopt, eal_short_options,
+ eal_long_options, &option_index)) != EOF) {
- default:
- if (opt < OPT_LONG_MIN_NUM && isprint(opt)) {
- RTE_LOG(ERR, EAL, "Option %c is not supported "
- "on Linux\n", opt);
- } else if (opt >= OPT_LONG_MIN_NUM &&
- opt < OPT_LONG_MAX_NUM) {
- RTE_LOG(ERR, EAL, "Option %s is not supported "
- "on Linux\n",
- eal_long_options[option_index].name);
- } else {
- RTE_LOG(ERR, EAL, "Option %d is not supported "
- "on Linux\n", opt);
- }
- eal_usage(prgname);
- ret = -1;
+ ret = eal_parse_option(opt, optarg, option_index, prgname);
+ if (ret < 0)
goto out;
- }
}
if (eal_adjust_config(&internal_config) != 0) {
@@ -774,7 +795,10 @@ rte_eal_init(int argc, char **argv)
thread_id = pthread_self();
- eal_reset_internal_config(&internal_config);
+ if (!run_once_reset_internal_config) {
+ eal_reset_internal_config(&internal_config);
+ run_once_reset_internal_config = 1;
+ }
/* set log level as early as possible */
eal_log_level_parse(argc, argv);
@@ -995,3 +1019,68 @@ rte_eal_check_module(const char *module_name)
/* Module has been found */
return 1;
}
+
+#ifdef RTE_LIBRTE_CFGFILE
+int
+rte_eal_configure(struct rte_cfgfile *cfg, char *prgname)
+{
+ int n_entries;
+ int i;
+ int opt;
+ int option_index;
+
+ if (cfg == NULL) {
+ rte_errno = -EINVAL;
+ return -1;
+ }
+
+ n_entries = rte_cfgfile_section_num_entries(cfg, "DPDK");
+
+ if (n_entries < 1) {
+ printf("No DPDK section entries in cfgfile object\n");
+ return 0;
+ }
+
+ struct rte_cfgfile_entry entries[n_entries];
+
+ if (n_entries !=
+ rte_cfgfile_section_entries(cfg, "DPDK", entries,
+ n_entries)) {
+ rte_eal_init_alert("Unexpected fault.");
+ rte_errno = EFAULT;
+ return -1;
+ }
+
+ if (!run_once_reset_internal_config) {
+ eal_reset_internal_config(&internal_config);
+ run_once_reset_internal_config = 1;
+ }
+
+ /* set log level as early as possible */
+ eal_log_level_cfg(cfg);
+
+ if (rte_eal_cpu_init() < 0) {
+ rte_eal_init_alert("Cannot detect lcores.");
+ rte_errno = ENOTSUP;
+ return -1;
+ }
+
+ for (i = 0; i < n_entries; i++) {
+ eal_getopt(entries[i].name, &opt, &option_index);
+
+ if (eal_parse_option(opt, entries[i].value,
+ option_index, prgname) != 0) {
+ rte_eal_init_alert("Invalid config file arguments.");
+ rte_errno = EINVAL;
+ return -1;
+ }
+ }
+
+ if (parse_vdev_devices(cfg) < 0) {
+ rte_eal_init_alert("Couldn't parse vdevs");
+ rte_errno = ENOMEM;
+ return -1;
+ }
+ return 0;
+}
+#endif
@@ -205,6 +205,7 @@ DPDK_17.08 {
rte_bus_find;
rte_bus_find_by_device;
rte_bus_find_by_name;
+ rte_eal_configure;
} DPDK_17.05;
@@ -81,7 +81,6 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_POWER) += -lrte_power
_LDLIBS-$(CONFIG_RTE_LIBRTE_TIMER) += -lrte_timer
_LDLIBS-$(CONFIG_RTE_LIBRTE_EFD) += -lrte_efd
-_LDLIBS-$(CONFIG_RTE_LIBRTE_CFGFILE) += -lrte_cfgfile
_LDLIBS-y += --whole-archive
@@ -97,6 +96,7 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_MEMPOOL) += -lrte_mempool
_LDLIBS-$(CONFIG_RTE_DRIVER_MEMPOOL_RING) += -lrte_mempool_ring
_LDLIBS-$(CONFIG_RTE_LIBRTE_RING) += -lrte_ring
_LDLIBS-$(CONFIG_RTE_LIBRTE_EAL) += -lrte_eal
+_LDLIBS-$(CONFIG_RTE_LIBRTE_CFGFILE) += -lrte_cfgfile
_LDLIBS-$(CONFIG_RTE_LIBRTE_CMDLINE) += -lrte_cmdline
_LDLIBS-$(CONFIG_RTE_LIBRTE_REORDER) += -lrte_reorder