From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 726052BF7 for ; Thu, 22 Mar 2018 15:11:19 +0100 (CET) Received: from cpe-2606-a000-111b-40b7-640c-26a-4e16-9225.dyn6.twc.com ([2606:a000:111b:40b7:640c:26a:4e16:9225] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1ez0vt-0007UO-VK; Thu, 22 Mar 2018 10:11:15 -0400 Date: Thu, 22 Mar 2018 10:10:37 -0400 From: Neil Horman To: "Wiles, Keith" Cc: Gaetan Rivet , "dev@dpdk.org" Message-ID: <20180322141037.GC6272@hmswarspite.think-freely.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) X-Spam-Score: -2.9 (--) X-Spam-Status: No 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: Thu, 22 Mar 2018 14:11:19 -0000 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? > > 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 :-) > +1, this really doesn't make much sense to me. Two parsing routines seems like its just asking for us to have to fix parsing bugs in two places. If allocation is a concern, I don't see why you can't just change the malloc in rte_kvargs_parse to an automatic allocation on the stack, or a preallocation set of kvargs that can be shared from init time. librte_kvargs isn't necessecarily the best parsing library ever, but its not bad, and it just seems wrong to go re-inventing the wheel. Neil > > > > Signed-off-by: Gaetan Rivet > > Regards, > Keith > >