From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by dpdk.org (Postfix) with ESMTP id 000AD322C for ; Thu, 24 Jan 2019 15:32:30 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 1B8AD16F1; Thu, 24 Jan 2019 09:32:29 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 24 Jan 2019 09:32:29 -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=hY58lGm3Pz1xrHeH8/3oPn0pKhQJ/mlufNppu9iuTv0=; b=lXGd57slOZ6W QSSRY5SvxQXrvtxCl58jW91goAj+/T1iLJAZ7D7n10oc+uHbm8TDAQPGTLQI7dpS GE4Bd0um0Je99vQcZj7PRp1wFRqrL4EZkAR8p0h6s5kuc1zgyQ3VNh4wHrh74x4k mhCs5dhdF+4VleM2vxgwNjHEZc3+Bik= 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=hY58lGm3Pz1xrHeH8/3oPn0pKhQJ/mlufNppu9iuT v0=; b=HiXQKwnGVn2vOFkSnnv3DhXHjfyeVWoVpcC5Pz+hKjShbm82DpCOeDs4I iEBdnh9N1ICLWOHnyUTh4wyfOP2cUQgPvOc8OCmyOwnYT5gKug9WZigJi4bTL0O+ 4DjUf+CAzL9QgfN7Y9FN4jvV+y9uqw2VtaD7Fq9+tkJSkCmW9h2fJyM/GagHC/BM TdNaS6T8/+dY5fF2uq/L7gT/YNYxj8rlBfxCXwxN5vekCD0DP0tNyC2HXeGOySG8 SeGIDp+DBRzonZkeeabiilRhsL6dOdCA3v0q2dRzY2oml7svAB2Xn2qQhWDrBi3f GclhLOP1eEfxrylWUX95lAMefS1ZA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledriedvgdeihecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufffkfgjfh gggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgrshcuofhonhhjrghlohhnuceo thhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukfhppeejjedrudefgedrvddtfe drudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvthenucevlhhushhtvghrufhiiigvpedt 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 B7C5B100E5; Thu, 24 Jan 2019 09:32:26 -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: Thu, 24 Jan 2019 15:32:24 +0100 Message-ID: <46920458.2e8qigbnFm@xps> In-Reply-To: References: <1499691101-184293-2-git-send-email-kubax.kozak@intel.com> <3950735.e0BHBgFYen@xps> 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: Thu, 24 Jan 2019 14:32:31 -0000 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?