[dpdk-dev] [PATCH v2 0/6] librte_cfgfile enhancements
thomas.monjalon at 6wind.com
Tue Mar 28 11:41:30 CEST 2017
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.
More information about the dev