From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f66.google.com (mail-wm0-f66.google.com [74.125.82.66]) by dpdk.org (Postfix) with ESMTP id 0949814E8 for ; Thu, 22 Mar 2018 17:28:07 +0100 (CET) Received: by mail-wm0-f66.google.com with SMTP id l9so17148615wmh.2 for ; Thu, 22 Mar 2018 09:28:07 -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=rbCRNF2fduIKGxBQG68h7hlGSrpZztBLiY8L+mL7ksc=; b=N6N0BwWpKSjNGVCCaUfQaofLZERCOIevauaWmiLsWnaTHnBBaQQqa7GUFKYODzBI0O tRlRSkhpJfGbHtGNgHDrw5FmeQmqcY+zGlomDiAaXRJN/4P1G8H84aC6/Op9akVa/5oa XWRVSRJRoF/1BtpV2FUML6L7RZ0p358e5dCPPQr3TsBau114kkRBAfyKtqY4DNVRv4M9 BXvkgnl4PbD77ooqYvZoatj/zgw32982I01xbpsdRlnUfDegHSG87boBRI+4wtohLbGV ve03JqfGOBsb7P6AA4H+S3K0t3zMWDAFEP+4BtB6uZXlLvmaQ+NGmUwP2XR6IeZIFm6r AF4w== 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=rbCRNF2fduIKGxBQG68h7hlGSrpZztBLiY8L+mL7ksc=; b=rVnoDKq1vSJX5rUac6cMZ29LlsAUUmpyK1OAJBm4uF6XCpAd6sXCPYFH8f6jLPbSks vXo0yTi4TnZCVExA0dRoOXKWD02FKgwDKFKLNR7r4MjvwbEQYj4eH7bEQuDsW/PNhfiF Ynr8+tfZD9lv4GOC1xvSc75xNYtKqZNW80p2Pzfswtuo23g08n7dJ5se6eJVY5m5Cgqz O9IPYrawSYnkayozNArSFUy8folr6gowQw6yml2KlEiyikD/chsBkcI9zilTCh4wofD3 v3E3pVoELtpvYAmPx1pS3hLsdbEFL4Vjjs8f91Yqd4UmjJTsYcx+eH4waoSK2A1SacXo 25tw== X-Gm-Message-State: AElRT7HrjLj9KfHiF7nkjh5J101GOU95I/ILhje+x6VG4zwjZibi49UX tbSErxoWnnsNZqzwF3cXY6eHXA== X-Google-Smtp-Source: AG47ELvL2ZLT014Nr19EWoPLUuPQQRpV2O1FjSfnT1A8XACYVFrrFDjKGvtx7tzBa2Ucm6rVEmcI+g== X-Received: by 10.28.15.78 with SMTP id 75mr5859545wmp.16.1521736087357; Thu, 22 Mar 2018 09:28:07 -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 m35sm14796678wrm.59.2018.03.22.09.28.05 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 22 Mar 2018 09:28:05 -0700 (PDT) Date: Thu, 22 Mar 2018 17:27:51 +0100 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Neil Horman Cc: "Wiles, Keith" , "dev@dpdk.org" Message-ID: <20180322162751.z2kjkpjcg6aw76kk@bidouze.vm.6wind.com> References: <20180322141037.GC6272@hmswarspite.think-freely.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20180322141037.GC6272@hmswarspite.think-freely.org> 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: Thu, 22 Mar 2018 16:28:08 -0000 On Thu, Mar 22, 2018 at 10:10:37AM -0400, Neil Horman wrote: > 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. I think the existing allocation scheme is fine for other usages (in drivers and so on). Not for what I wanted to do. > 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. > It serves a different purpose than the one I'm pursuing. This helper is lightweight and private. If I wanted to integrate my needs with librte_kvargs, I would be adding new functionalities, making it more complex, and for a use-case that is useless for the vast majority of users of the lib. If that's really an issue, I'm better off simply removing rte_parse_kv and writing the parsing by hand within my function. This would be ugly and tedious, but less than moving librte_kvargs within EAL and changing it to my needs. -- Gaëtan Rivet 6WIND