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 C1CA3559A for <dev@dpdk.org>; Thu, 24 Jan 2019 18:45:17 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 58F8016DF; Thu, 24 Jan 2019 12:45:16 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 24 Jan 2019 12:45:17 -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=fOTxuWwKRGzgb4WUQvDl6dzGz29FqvBi1lYOnfNqAPg=; b=szz6RkChWSz/ 4q/63bhrDsr2adkedX1oPT22IUvbunPXFIIYzYlokmaobFYMNPhm87BXZiI3FrIj twGgOGZn3lVxrJrADWQYOT0N+5p0IkcX5GW9BotenSqa/vqtg+kh7FjKnVpYdJXL QfAjkyxS7/0Lgg/9p080e+4Np7dWsUE= 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=fOTxuWwKRGzgb4WUQvDl6dzGz29FqvBi1lYOnfNqA Pg=; b=bkS8W0uWcMrwgEZRL1TdcgglgOnMNDoSQLoTPrLwWRrW9d0PSqhG0BNse pOq6grQURZ0jOa5r5AO6B2uWmlyOXX/QuE2KkxEHopKfi2+Yyj6Bm/k+W3/H8YKy oXCqkHiEjt51mWZ1OVLSiA/ZXITfvQ1nRKcnItIVXtducx3JFe4yQ1N0k/NY5Hhq fEUJ+K7n1BPEmxkiLPTNofPiISKyPDczFEEpq/91NmCmwF11LJHPsSGe3TOPGgwL pCSarSFH3fWp1/pY8Xd2E4HvyVfv8Uf+WJG/8uco+j+n8BRnjRoYwfvkHKMU/K75 iLwaRUAw7I5MnUZngy6uyrFBm6Q4g== X-ME-Sender: <xms:qvlJXJLLyeNoLSkGJH84kw3hdBL4vdpcWQ2MbpbB61ex12yj2vKnIw> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledriedvgddutdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffufffkjg hfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghsucfoohhnjhgrlhhonhcu oehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkphepjeejrddufeeirddvtd dvrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: <xmx:q_lJXJbOjTGQyLM2qBU4XNgcjY3YHCJnjnVtn5KemUbK88tQ_-7KTw> <xmx:q_lJXMum7siSi2SVA51x_DozeeMLklOyHD9c-U190cNF93OKVEYHDg> <xmx:q_lJXOtvmtMBHbdbtTJvPAnJvSf0F56gDTQ6y9eA0Ruq2OrzQosdHg> <xmx:q_lJXIQj8MlP8SKKzDYKo-jgMzlmt4WiprA_x-a3GZbVr54jogPR8A> Received: from xps.localnet (184.202.136.77.rev.sfr.net [77.136.202.184]) by mail.messagingengine.com (Postfix) with ESMTPA id C827810087; Thu, 24 Jan 2019 12:45:11 -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 18:45:09 +0100 Message-ID: <7547888.LVYzlvvcug@xps> In-Reply-To: <ed3a5f16-7305-b5bc-1df3-4b7e16f05b14@intel.com> References: <1499691101-184293-2-git-send-email-kubax.kozak@intel.com> <30360779.GShNj3nc5p@xps> <ed3a5f16-7305-b5bc-1df3-4b7e16f05b14@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 17:45:18 -0000 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.