From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bruce Richardson Subject: Re: [PATCH v2 0/6] librte_cfgfile enhancements Date: Tue, 28 Mar 2017 10:22:37 +0100 Message-ID: <20170328092237.GB16008@bricha3-MOBL3.ger.corp.intel.com> References: <1488482971-170522-1-git-send-email-allain.legacy@windriver.com> <1489065060-98370-1-git-send-email-allain.legacy@windriver.com> <5672709.vjmmP8HFrE@xps13> <20170328091828.GA16008@bricha3-MOBL3.ger.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Allain Legacy , cristian.dumitrescu@intel.com, dev@dpdk.org, yuanhan.liu@linux.intel.com To: Thomas Monjalon Return-path: Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id ACD13D1E4 for ; Tue, 28 Mar 2017 11:22:41 +0200 (CEST) Content-Disposition: inline In-Reply-To: <20170328091828.GA16008@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" 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. 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. Thoughts? /Bruce