From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v2 0/6] librte_cfgfile enhancements Date: Tue, 28 Mar 2017 11:41:30 +0200 Message-ID: <22590962.V8IQgtpKlO@xps13> 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: Allain Legacy , cristian.dumitrescu@intel.com, dev@dpdk.org, yuanhan.liu@linux.intel.com To: Bruce Richardson 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) In-Reply-To: <20170328092237.GB16008@bricha3-MOBL3.ger.corp.intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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.