From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-f45.google.com (mail-vk0-f45.google.com [209.85.213.45]) by dpdk.org (Postfix) with ESMTP id 2BF4A568A for ; Wed, 10 Feb 2016 20:13:16 +0100 (CET) Received: by mail-vk0-f45.google.com with SMTP id e185so20753509vkb.1 for ; Wed, 10 Feb 2016 11:13:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bigswitch-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mqiuJPFXW+EO6b8umBnwqfNn058eZRRylPibCHiVNMc=; b=vQfDggGoKJHUxoon+ZytVF6capUsBqTUuk+eVKUAXEuFq1zhz9JiSM6XPmSoSB/iC9 5vmvj3GzS9yeKgKVKCBqVwcoplKNCGXuCauMTewoOVyTAvVuUtniaGg5VCTAnEphWW2V Pxz/VgkyRAEYddga8cuUvW9KVddPGDtX9Am+m/05Re/Izx7RokAo+GCGM9yZU65HEE1X D2dsRSUth2BMbAyAmiIl6xOwW3ic92fJ3gK9ATKZ3ZbX9/v+dQfyXrYuNlaWNa4DUXn0 jByXqOLgpbvAhmH41kkJZeGCAvFIbvhVs/YpOA/Je2kwXYNo0XpGYiuSlY8UAZ6z4r+b 8sOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mqiuJPFXW+EO6b8umBnwqfNn058eZRRylPibCHiVNMc=; b=OHh1aHRFXvYdW79sarIcea3iVSs2GJiHN1iau5Mw1yVdf3/BBqCq1GaKqLJGKNG4VE NwrK9ekcFaa3IxBpG2wcyz2PN6iEqMmDUFYhgxUi9PnZZESGSd2bD27szykBa0S01bff dWFUoLR+Ey0fkCvmMtfF9Nn+LznOj0GagCDx9nDXyKY6ezMpo+SewedSVY2N9aWSvbzA oDWvo5L9QCbUU9dg1BR65KlRvi53UjQs8RdnbRrTykJy+cpE72q/Sf6R7FMw6niac/nK aMW8ciljTas3s4DIFeO0GCBSK+9+86meKJJBKxOTc5fTOTz+ZCcr9g9x/5cuILnaTlNj Ee0g== X-Gm-Message-State: AG10YOSQMsNgWiCc/YzO3PmLjAnH0i50WLOHQk7xKWBZrRV8VFS+qLSdrfuJvxXapBpph+Id9pFp2+EysEpoSEay MIME-Version: 1.0 X-Received: by 10.31.0.215 with SMTP id 206mr32030741vka.22.1455131595704; Wed, 10 Feb 2016 11:13:15 -0800 (PST) Received: by 10.31.129.9 with HTTP; Wed, 10 Feb 2016 11:13:15 -0800 (PST) In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D891264794DACE@IRSMSX108.ger.corp.intel.com> References: <1453003104-19107-1-git-send-email-rlane@bigswitch.com> <1453178510-113435-1-git-send-email-rlane@bigswitch.com> <3EB4FA525960D640B5BDFFD6A3D891264794DACE@IRSMSX108.ger.corp.intel.com> Date: Wed, 10 Feb 2016 11:13:15 -0800 Message-ID: From: Rich Lane To: "Dumitrescu, Cristian" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v2] cfgfile: support looking up sections by index X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Feb 2016 19:13:16 -0000 On Tue, Feb 2, 2016 at 7:10 AM, Dumitrescu, Cristian < cristian.dumitrescu@intel.com> wrote: > > > > -----Original Message----- > > From: Rich Lane [mailto:rich.lane@bigswitch.com] > > Sent: Tuesday, January 19, 2016 4:42 AM > > To: dev@dpdk.org > > Cc: Dumitrescu, Cristian ; Panu > Matilainen > > > > Subject: [PATCH v2] cfgfile: support looking up sections by index > > > > This is useful when sections have duplicate names. > > Hi Rich, > > You are right, I can see this is needed to allow multiple sections with > identical name in the same configuration file. When sections with the same > name are not allowed, then this is not needed, as the current API is > sufficient. > > To me, having several sections with the same name does not look like a > good idea, in fact it might look like an application design flaw, as > differentiating between sections with the same name can only done based on > the position of the section in the configuration file, which is an error > prone option. Some examples: > 1. While maintaining a large config file, keeping a specific section at a > fixed position quickly becomes a pain, and shifting the position of the > section up or down can completely change the application behavior; > 2. Using basic pre-processors (like CPP or M4) or scripts, the master > configuration file can include other configuration files, with the > inclusion of each decided at run-time based on application command line > parameters, so the position of certain sections is actually not known until > run-time. > > Can you provide some examples when having multiple sections with the same > name is a key requirement? > My application uses a config file to assign RX/TX queues to cores. Ports and cores have names (e.g. "core.fwd0"), but there's no reason to name queues. The order of the queue sections is unimportant. > A straight forward workaround to having multiple sections with the same > name is to add a number to the name of each such section. Using the current > API, all the sections with the same prefix name can be read gracefully. As > an example, the ip_pipeline application allows multiple sections with the > same name prefix but a different number prefix: > PIPELINE0, PIPELINE1, ... > LINK0, LINK1, ... > MEMPOOL0, MEMPOOL1, ... > RXQ0.0, RXQ0.1, RXQ1.0, ... > TXQ0.0, TXQ0.1, TXQ1.0, ... > > Is there a reason why this approach is not acceptable for your application? > It is less usable. The person writing the config file must generate those suffixes which are irrelevant to what they're trying to express. The sole effect is to add another source of errors. Additionally, this API allows reading a config file in linear instead of quadratic time (wrt number of sections). While my config files aren't long enough to make this a requirement it certainly seems desirable.