From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id 71980271 for ; Wed, 23 Jan 2019 21:27:04 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 0CDB9221C7; Wed, 23 Jan 2019 15:27:03 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 23 Jan 2019 15:27:03 -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=9I5j2C3eA1MXp8KgWw9cioDNB54puCmGGhzgvUJL4ZQ=; b=FORtqcSWvvDt t0Rd0VB/AhldBF9E7av33ZeW53a9X3jcNZdeomu0tPpv5diYSw6BbkWt82afDyFa orDpq3s5T6e4ttE8PZuVANwSpd5EClo3AFQuNKHFb/EMhJBH/8NYlI7Ht5KX6P7O xPI5HJnBnDmvAdhXR5Xx7yNzHBgwkLY= 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=9I5j2C3eA1MXp8KgWw9cioDNB54puCmGGhzgvUJL4 ZQ=; b=cQn2l/hIgMghGvyERIHZmXrv3rOOpI81krBaHfAVNpZG5YbhLs7ySl8LO jFmi0UeIHyjsLRCClRJUUHQ3Iixx3EpnngwiIne9fsdi/Q13aUtKGCKR70otrcoq rPyPRaGrWWRIPFcQg6+uGa549TQZsvHbChloY81WoGLUFLsltEkalyUlLNOc7oo1 YIWdTbZsDUcZ08+xG4JIcZBAAZ29wif5/tcK5wM3xtXJZ/FLooAsd51fhi+5RBR/ j812vsY8JESKuRloLdio11TkypOmITATRHoviwkoCNmXs93f5h3rHj3Vjt4AhHQp 2MQDWjptiJ/O0/X4cswhVbFKZEeng== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledriedtgddufeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffufffkjg hfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghsucfoohhnjhgrlhhonhcu oehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkphepjeejrddufeegrddvtd efrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id D1023100E4; Wed, 23 Jan 2019 15:27:00 -0500 (EST) From: Thomas Monjalon To: Ferruh Yigit 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 Date: Wed, 23 Jan 2019 21:26:58 +0100 Message-ID: <3950735.e0BHBgFYen@xps> In-Reply-To: <0d99715f-d628-3719-edcc-62991f91e7f2@intel.com> References: <1499691101-184293-2-git-send-email-kubax.kozak@intel.com> <1499940470-31628-1-git-send-email-kubax.kozak@intel.com> <0d99715f-d628-3719-edcc-62991f91e7f2@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 20:27:04 -0000 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.