From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f194.google.com (mail-wr0-f194.google.com [209.85.128.194]) by dpdk.org (Postfix) with ESMTP id B9F364C9D for ; Wed, 21 Mar 2018 18:58:22 +0100 (CET) Received: by mail-wr0-f194.google.com with SMTP id z8so6099594wrh.7 for ; Wed, 21 Mar 2018 10:58:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=pS5+LYlgvcb811FtHhjtlF1aBYAQuVozSGlgnsXhjzQ=; b=Ll7vrsYuw3OOTNZUF6vgrmWgya+zWckSv5rQTKCRKo1xUTGN8K/3V15KuudO20CWxW /zlA09ZZ5QoftF/u4PtiOgsPsdBuMaHdhMGpX2QEFw4/b3ntppIS2wFDGMx3N8Tx7+vw 4WdISkndCPAju6yxjrc3n9JKdVsJ5hrAOIT7scKja/K6BaEknc+UihhWBlYueWAnIztu 7z2lnYCXGvwdD6ufXQCKEpgGw6SYizXNCcxPqdW+JVSkVFLxL9EWz+royGRSnJuP6oe9 gpxvINmJLx753g1EAv/sFlxRxVXWptKMEp2TPicDCg67ENsxFNBpF8WGenGUr6Hgw1td tdpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=pS5+LYlgvcb811FtHhjtlF1aBYAQuVozSGlgnsXhjzQ=; b=ZTmvlOPc0WgcU93BpAEsLKxogxrT/IGFu+Blm/CB944HAvf9VlSOrBGutyp10KcNQ4 H4QEUvaGKJ5R8qTdl35T2IWRVQAhcouKKeFic3UUL4/VmGTmII5v/9IqywKqson/1Ysb mZG2bmKmcg1W77YhJipKBv9WxuGhBTUkE+N+ZoFfNVgd18sipvkADEE30xorsodkLvQq //yUFFgm+h/IlxUajzUd4qkYkhPZIx93eM9h92S1HKwh+vv5Jr+dp+Lkew1URp//6xTv aHNQOy5FWNwwsLsM91a1kahl3Rb9UO1F99UpJdU+/7po7ieEpInOvdYGMrGNq0glt4wM QN+Q== X-Gm-Message-State: AElRT7Ggw04FDVJwNjqSYsUZ254RRzHKvFsTXr3j5C46hsddkpaOHIwr +oE/fiWAW0AzMbisQUNLSMfWzw== X-Google-Smtp-Source: AG47ELtFaTcKuw6Bt2DVtmhFxWT+8kKEjgl2DiDpateWVDygvUuv34vjzD1jTthGREWZmJDrTGH+0w== X-Received: by 10.223.139.199 with SMTP id w7mr16024392wra.219.1521655102169; Wed, 21 Mar 2018 10:58:22 -0700 (PDT) Received: from bidouze.vm.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id l1sm4302518wmh.25.2018.03.21.10.58.21 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 21 Mar 2018 10:58:21 -0700 (PDT) Date: Wed, 21 Mar 2018 18:58:07 +0100 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: "Wiles, Keith" Cc: "dev@dpdk.org" Message-ID: <20180321175807.gedmgrxhiiwz5btj@bidouze.vm.6wind.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Subject: Re: [dpdk-dev] [PATCH v2 04/18] eal: add lightweight kvarg parsing utility 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, 21 Mar 2018 17:58:22 -0000 Hello Keith, On Wed, Mar 21, 2018 at 05:32:24PM +0000, Wiles, Keith wrote: > > > > On Mar 21, 2018, at 12:15 PM, Gaetan Rivet wrote: > > > > This library offers a quick way to parse parameters passed with a > > key=value syntax. > > > > A single function is needed and finds the relevant element within the > > text. No dynamic allocation is performed. It is possible to chain the > > parsing of each pairs for quickly scanning a list. > > > > This utility is private to the EAL and should allow avoiding having to > > move around the more complete librte_kvargs. > > What is the big advantage with this code and the librte_kvargs code. Is it just no allocation, rte_kvargs needs to be build before parts of EAL or what? > Pretty much, yes. I needed something lean and simple. > My concern is we have now two flavors one in EAL and one in librte_kvargs, would it not be more reasonable to improve rte_kvargs to remove your objections? I am all for fast, better, stronger code :-) > I hear you. I decided this was worth the trade-off. librte_kvargs does the iteration on a kvlist in one-line. It processes the input text and mangle as needed to be able to do so. Drivers using it will be able to declare first a set of acceptable keys, meaning that it is complementary to having a usage-help and more stringent input validation. rte_kvargs does none of it. This means that each user would have to re-implement checks by hand, and reviewers would need to enforce that they are done, etc. So, IMO, different use-cases. In this context, I think making the effort of moving around librte_kvargs within the EAL, tweaking its use for my needs, does not make much sense. It would complicate its implementation only for one less private function. If people do not like using librte_kvargs, it could maybe evolve, be rewritten, then all drivers would need to follow suit, etc. But I haven't seen the need personally. Regards, -- Gaëtan Rivet 6WIND