From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <thomas@monjalon.net> Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by dpdk.org (Postfix) with ESMTP id 568294CA0 for <dev@dpdk.org>; Thu, 24 Jan 2019 17:06:33 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 783681647; Thu, 24 Jan 2019 11:06:31 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 24 Jan 2019 11:06:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=qGku/s5luwAE5hQL3w1+C7xdvvnLp4LMHIbE4/sxHLE=; b=pNeQ9sqqzxKN JE/KNc7vWnzrNtOAPsgvn/L92/BF+kXTV2dFJz6fDELztoBbObWV5LxqmaPrF/SO TXRVnngjCsjW42yav7jknh3LJjTaUZ3xfgOWOda705DArGA6T4+ZBeuwJwsUfOAI cEn3l3kYKGsMgZmkrP+/WXeHJX3w6+Y= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=qGku/s5luwAE5hQL3w1+C7xdvvnLp4LMHIbE4/sxH LE=; b=XPwCDp6yOQ5woL71qCByyOX9tDzweI5MQlxYTDbeDPNO1z4GNEAIQyMb/ L8vHXLn91ZDbeQsz61yJxbXX9WLr3M2MFK0cs6qQ9FVdcr7pv3KE89kW3inPZbAF KOHMYGmsKPhi5sr+zfcRgM5ltaHPGviYRBfKaza7fm75ujEJMlpRoB+iaCntpxJw 1NEMqrZ9pBvCWpFm5JIIrh5xxSa200LJvmpry8zuT1mnUxNUktoy3ArcTQE6hEfu gtX1ZfHeKd1P9DDKKaZUAbEShx+0t+iD46DOOTiCJPd0YU8Q32OsahUVixEkh8uY 7TX9GkvpX47vJWPoUs4wQGuWmuZrQ== X-ME-Sender: <xms:huJJXHCdF2qzKkS7D8eh8963GFqkvmFJH1GXmPqVSXr99hAHzAunNA> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledriedvgdekfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufffkfgjfh gggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgrshcuofhonhhjrghlohhnuceo thhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukfhppeejjedrudefgedrvddtfe drudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: <xmx:huJJXBye5UfiOO-KzHwTHC5Qu6xTetrCA9ZW1Tndah02EvhX0R2smw> <xmx:huJJXNlmTLQVXTYJ9N-fNk_dSz__v7lKa5z7J_vhTsOGF6FhegBaXw> <xmx:huJJXOHJ-XVSPq64GBsYxhvV3yceagNsYEF-9xpGW34iljlpncSR_g> <xmx:h-JJXOIo7tfLD-uSoaQDb4nt_ewPK05H-OgNr2FtnUJv3k9LdoC9aw> Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 1C03F10086; Thu, 24 Jan 2019 11:06:29 -0500 (EST) From: Thomas Monjalon <thomas@monjalon.net> To: Ferruh Yigit <ferruh.yigit@intel.com> Cc: Kuba Kozak <kubax.kozak@intel.com>, deepak.k.jain@intel.com, bruce.richardson@intel.com, michalx.k.jastrzebski@intel.com, jacekx.piasecki@intel.com, dpdk-dev <dev@dpdk.org>, Stephen Hemminger <stephen@networkplumber.org>, Kevin Traynor <ktraynor@redhat.com>, David Marchand <david.marchand@redhat.com> Date: Thu, 24 Jan 2019 17:06:27 +0100 Message-ID: <30360779.GShNj3nc5p@xps> In-Reply-To: <631f689c-a4a4-bc91-c8ec-8449fea20f5f@intel.com> References: <1499691101-184293-2-git-send-email-kubax.kozak@intel.com> <46920458.2e8qigbnFm@xps> <631f689c-a4a4-bc91-c8ec-8449fea20f5f@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v5 0/3] EAL change for using a config file for DPDK X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Thu, 24 Jan 2019 16:06:33 -0000 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.