From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 1979DA052F; Wed, 29 Jan 2020 20:19:50 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 23BEC1BFD4; Wed, 29 Jan 2020 20:19:49 +0100 (CET) Received: from mail-pg1-f193.google.com (mail-pg1-f193.google.com [209.85.215.193]) by dpdk.org (Postfix) with ESMTP id 826381BFCE for ; Wed, 29 Jan 2020 20:19:47 +0100 (CET) Received: by mail-pg1-f193.google.com with SMTP id a33so294850pgm.5 for ; Wed, 29 Jan 2020 11:19:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=CLB3noQjdDYlF1t9TW6OI0dDXmtRmKgWf00fZ0/FRnE=; b=Nv0YZGz0sgDgAGEV+tiggTBXvlVGANVPRiDwTAlwdJATrNWemYyH+PAQvZgKqJXkZ8 yrA9IIn1q7BPMvA/3dFMH2tZ66YJMON2Y6OO4d5sm4WqsnDR29mWzEhs7XAd1SiuBdwd TymvnCKKLRznWeVnX2KKNWCueR8D+pu6juj7ndAnVkSqVr5IfbwLXG6HX0Df5J6cMEHC wsF6/XTHxpnYxCphR5w/CjalAqdoCrHGlTj6225f4Z/Z8XVUmjd1fxtM8iE9X0kqXs27 4PdGyv2Zfp/S5IFJTsg/qFH0rkT9ZFVh64QaYUDbpxOq/bVO0MQswAggO21atK978RNK 64Aw== 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:in-reply-to :references:mime-version:content-transfer-encoding; bh=CLB3noQjdDYlF1t9TW6OI0dDXmtRmKgWf00fZ0/FRnE=; b=BJnBpGlHTotnSos8V8gzZHflKsxHnBCMJglkTeuKtgxpIL88bKogo6C6Cm7T7a/WOW y1ki/wjGr167h/jfiIkJ5jqfHtkdQhAbBs/p4ORC1O5nNo1xduiTX/vthWc7NlIpzQJx A+wSkR0v6kVYxf/sJtQaR/UHGeGgbPpPTX2z3ltgAgkCVr0S/ZbMU/GIq/2vsAxwfT6a 3pMxiHlYC8fmZqFASq4mxOJJ/QXaD+uis/51lM1UrOornGpyVrGdV6EFHBG7OYFpcYmw +iZQ1OgMoBYRyXoZbtwVW/QDtOOO6s2I9I+S8Y6Ha1wqbcq48lyk9IoUY03WdcsuHxQP nfIQ== X-Gm-Message-State: APjAAAW/xyVgTICjzOWj3Rf/wenSXdT/vHayPl4CGAcwzjSo4dpetuXO 7bU6kpf0baxtD+rS0iLmZrdT1Q== X-Google-Smtp-Source: APXvYqzmOZuUF6t8XsY/zIuf29HNiI7ALmFdgDLsXsqK7y1Rn68zn+nUQpVhfIfb8TaSM7PtsXqPiQ== X-Received: by 2002:a63:6d8d:: with SMTP id i135mr636652pgc.90.1580325585930; Wed, 29 Jan 2020 11:19:45 -0800 (PST) Received: from hermes.lan (204-195-22-127.wavecable.com. [204.195.22.127]) by smtp.gmail.com with ESMTPSA id z26sm3482177pgu.80.2020.01.29.11.19.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Jan 2020 11:19:45 -0800 (PST) Date: Wed, 29 Jan 2020 11:19:37 -0800 From: Stephen Hemminger To: Ferruh Yigit Cc: David Marchand , Thomas Monjalon , Hariprasad Govindharajan , dev Message-ID: <20200129111937.031a16a6@hermes.lan> In-Reply-To: <6e50daed-d368-215b-22da-fc7332ded22c@intel.com> References: <1580121053-26083-1-git-send-email-hariprasad.govindharajan@intel.com> <1580121053-26083-3-git-send-email-hariprasad.govindharajan@intel.com> <1689bec2-91f3-77cd-8604-f7123023b109@intel.com> <6e50daed-d368-215b-22da-fc7332ded22c@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH 2/2] eal: add eal_parse_optionlist to parse user input 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Wed, 29 Jan 2020 18:07:05 +0000 Ferruh Yigit wrote: > On 1/29/2020 5:44 PM, David Marchand wrote: > > On Tue, Jan 28, 2020 at 6:35 PM Ferruh Yigit wrote: > >> On 1/27/2020 10:30 AM, Hariprasad Govindharajan wrote: > >>> In current version, there is a function which parses > >>> the corelist based on user value. A new generic > >>> function eal_parse_optionlist is added which will > >>> parse corelist as well as similar user input so > >>> that we can use it as a public API too. > >>> > >>> Signed-off-by: Hariprasad Govindharajan > >> > >> Hi David, > >> > >> Overall this patchset is to add '--portlist' command to testpmd and remove > >> existing 64 port limitation. > >> > >> And in this patch re-uses the exiting parser function in eal and converts it to > >> API, question is if eal is good place to have this API, what do you think about it? > > > > Exporting string parsers from the EAL has little value. > > Ok we avoid code duplication (and I can see other places in the tree > > where it might be used), but in the end we will have to maintain this > > API in the ABI when it enters the stable ABI. > > > > I am for avoiding this. > > > > > > The same function can be used in some sample applications too (which are using > port mask), so instead of duplicating it multiple times, it would be nice to > have this function somewhere that applications can use. > > Does it makes sense to have a rte_util.c (under in eal or as a separate library) > to have this kind of application helper functions? It makes sense to have a rte library that handles arbitrary size bitvector and has string handling functions. Kind of like what kernel has for the cpuset parsing. This could be used for cpus in EAL and port-masks or other arrays in applications. But just doing copy/paste of existing code without thinking about how API should work is a bad idea.