From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v5 0/3] EAL change for using a config file for DPDK Date: Thu, 24 Jan 2019 18:45:09 +0100 Message-ID: <7547888.LVYzlvvcug@xps> References: <1499691101-184293-2-git-send-email-kubax.kozak@intel.com> <30360779.GShNj3nc5p@xps> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: Kuba Kozak , deepak.k.jain@intel.com, bruce.richardson@intel.com, michalx.k.jastrzebski@intel.com, jacekx.piasecki@intel.com, dpdk-dev , Stephen Hemminger , Kevin Traynor , David Marchand To: Ferruh Yigit Return-path: Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by dpdk.org (Postfix) with ESMTP id C1CA3559A for ; Thu, 24 Jan 2019 18:45:17 +0100 (CET) In-Reply-To: List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 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 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.