From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f174.google.com (mail-wr0-f174.google.com [209.85.128.174]) by dpdk.org (Postfix) with ESMTP id 557B3CF8A for ; Tue, 28 Mar 2017 11:41:32 +0200 (CEST) Received: by mail-wr0-f174.google.com with SMTP id u1so95635956wra.2 for ; Tue, 28 Mar 2017 02:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=Xi0s+Mzlscw+XL+VO15yaZ/ht7N68hYQwBZivF7aCKE=; b=p5rhUR7kIi0FcSgjwO9WE5OPADUQBnWS4syn7G1kV7ZgDrf2FpNw2pPDwCHGqZstvc snpvJ6YLJJgc0vbC+u036hp+fk64dWj7fBmIxbayMOkGZfx3l5FMBsZ8JE6U7ohjr5Iy lc3nVBUY2L3S80NdwMIxZXIO71b+9tX02BqXUJM5C1SvLna/Yd0NzsmES6mm+8turKTc Jj16m9Ilw5dhRXQFpSHfazl+/lZOy4e3Ql4xvltW6Ocd3U+FTqnNaQab6rbMEph4p7lB 6zdP9B2AtxKM7sW2KoLSCRRjMoAa/xOsC1u01tVXUK3dDUjssUtlKPQvp3sgK7Y2JmZp d+6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=Xi0s+Mzlscw+XL+VO15yaZ/ht7N68hYQwBZivF7aCKE=; b=N977HHLT8D12fpcRCr7qQHqUGt2wvK6Gmud/5c950yvWWScAjQvbvdtu2znomOQA90 ILSSv1HStpfd/YoQIfUT1pdA6X/yhsZql8r7SKGCCOCpPse9saasiDyPSNYrYOsCG0dP XsMmIsOtk+SwBOCKcWYCvFMMh7SOWR3feiXWPBVvjNfc/YEWSVhTuxNbcS7RHLeVgWxq eGSuI0rbzWm6tCqLgENHUC0Q3SRayy5Iz1nXIekhZQvZHK2kUh6QaCIznbEr0hXlL4KP 0VesgRq6QqlLcPjH100uZi/zr+Wz6axPjsljVROVPg2ZNu+OScuEOYATtAFKEgxP0/Cn kNXQ== X-Gm-Message-State: AFeK/H2do2W1V/DnJ/+2qZxJT6StTX/aHQmqChhHRs7L9vRvcAhmrjpnIVR6eDRk/VXTxpvs X-Received: by 10.28.10.70 with SMTP id 67mr3101240wmk.131.1490694091865; Tue, 28 Mar 2017 02:41:31 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id 65sm4102964wri.68.2017.03.28.02.41.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 02:41:31 -0700 (PDT) From: Thomas Monjalon To: Bruce Richardson Cc: Allain Legacy , cristian.dumitrescu@intel.com, dev@dpdk.org, yuanhan.liu@linux.intel.com Date: Tue, 28 Mar 2017 11:41:30 +0200 Message-ID: <22590962.V8IQgtpKlO@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20170328092237.GB16008@bricha3-MOBL3.ger.corp.intel.com> References: <1488482971-170522-1-git-send-email-allain.legacy@windriver.com> <20170328091828.GA16008@bricha3-MOBL3.ger.corp.intel.com> <20170328092237.GB16008@bricha3-MOBL3.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 0/6] librte_cfgfile enhancements 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: Tue, 28 Mar 2017 09:41:32 -0000 2017-03-28 10:22, Bruce Richardson: > On Tue, Mar 28, 2017 at 10:18:28AM +0100, Bruce Richardson wrote: > > On Tue, Mar 28, 2017 at 10:29:44AM +0200, Thomas Monjalon wrote: > > > 2017-03-09 08:10, Allain Legacy: > > > > This patchset includes some minor enhancements that we have developped for > > > > our DPDK application. We would like to contribute them upstream to help > > > > ease adoption of the DPDK by anyone looking for this type of > > > > functionality. The commit logs on each patch should be self-sufficient in > > > > explaining the intent and purpose. > > > > > > This series is small enough to be merged. > > > However, in the long term, we should not have this kind of library in DPDK. > > > > > > librte_cfgfile is used by the examples ip_pipeline and qos_sched. > > > I think the purpose of an example is to show some simple code demonstrating > > > a feature. > > > Examples using a configuration file are closer to a complete application. > > > > > > Anyway, why not use an external library like this one? > > > https://github.com/vstakhov/libucl > > > > Because as a general rule, anything adding in external dependencies needs > > to be disabled by default. This leads to the catch-22 situation I > > flagged before, and had no follow-up on. There is no way right now for > > someone to put in extra functionality like this into DPDK and have it > > default enabled. If you try putting it into DPDK directly, it will be > > rejected as duplicating other libs, but if you re-use the libs, it will > > be disabled by default as adding in an extra dependency. > > > > /Bruce > > As follow-up to my own mail, for this specific library example, I > wouldn't look to remove it from DPDK anyway. Parsing ini files is fairly > trivial, so I think it's not a big deal to keep our own version and not > have an external dependency - especially since it's already there and not > a big maintenance burden. Removing this lib would not disable anything as it is used only by examples. I don't see what would be the issue. We just have to download the lib when building the example app. It can be done quite easily in the makefile. > For newer functionalty, we do need clear guidelines as to when it is > acceptable to add new dependencies to DPDK. I'd love to see us enable > the PCAP PMD by default, for instance, and I think Sergio has recently > proposed we also require libnuma on Linux. We won't include libpcap or libnuma. The only thing we should do is to make easier to view and enable dependencies.