[dpdk-dev] [PATCH v2 0/6] librte_cfgfile enhancements

[Thomas Monjalon]

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.