[dpdk-dev] [RFCv2 00/40] Building DPDK with meson and ninja

Luca Boccassi luca.boccassi at gmail.com
Fri Aug 18 11:33:00 CEST 2017


On Fri, 2017-08-18 at 09:35 +0100, Bruce Richardson wrote:
> On Thu, Aug 17, 2017 at 04:25:36PM +0100, Luca Boccassi wrote:
> > On Thu, 2017-08-17 at 16:10 +0200, Marco Varlese wrote:
> > > Hi Bruce,
> > > 
> > > On Mon, 2017-08-14 at 10:51 +0100, Bruce Richardson wrote:
> > > > Following on from previous RFC [http://dpdk.org/dev/patchwork/p
> > > > atch
> > > > /25104/]
> > > > here is a second draft implementation for building DPDK with
> > > > meson
> > > > and
> > > > ninja. While still not building all of DPDK, and needing patch
> > > > cleanup so
> > > > that patches don't overwrite previous work, it is more complete
> > > > in
> > > > many
> > > > ways than the previous version and includes:
> > > > 
> > > > * dynamic build configuration e.g. building pcap driver only if
> > > > pcap is
> > > >   found, only build af_packet if the target is linux, and only
> > > > building QAT
> > > >   and openssl crypto drivers if libcrypto is found
> > > > * support for pmdinfo inside the PMDs(for shared builds) and
> > > > binaries (for
> > > >   static builds)
> > > > * generalized/standardized way of building libs and drivers,
> > > > though
> > > > the
> > > >   drivers code still needs generalization at the driver, rather
> > > > than
> > > >   driver-class level.
> > > > * support for having a pkgconfig file for DPDK on install, and
> > > > helloworld
> > > >   and l2fwd can be built using the pkgconfig info (via make,
> > > > not
> > > > ninja)
> > > > * support for library versions
> > > > * an implementation for FreeBSD as well as Linux
> > > > * all libraries are included in the build, as well as a number
> > > > of
> > > > NIC,
> > > >   crypto, and mempool drivers
> > > > * the igb_uio kernel module is build via the kernel Kbuild
> > > > system
> > > > as part
> > > >   of a meson/ninja DPDK build
> > > 
> > > This is really great to see. I do have one suggestion.
> > > Would it be possible to version the libraries built by the build-
> > > system
> > > following the same version of the DPDK release?
> > > 
> > > For instance, in DPDK 17.08 we currently have:
> > > # objdump -p librte_pmd_ixgbe.so.1 |grep SONAME
> > >   SONAME               librte_pmd_ixgbe.so.1
> > > 
> > > Would it make sense to instead have librte_pmd_ixgbe.so.17.08
> > > 
> > > I think it would help to facilitate the installation of multiple
> > > DPDK
> > > library
> > > versions on the same system. 
> > > 
> > > For example, we could have the following scenario:
> > > 
> > > 1) OpenVSwithc linked with version 17.02 of DPDK
> > > 2) VPP linked with version 17.08 of DPDK
> > > 3) DPDK 18.xx installed in the system for any cutting-edge
> > > application
> > > prototyping.
> > > 
> > > Is this something which could be incorporated as part of this
> > > work?
> > 
> > Christian sent a patch a while ago, which was merged, to enable
> > this in
> > the current build system, it's the CONFIG_RTE_MAJOR_ABI option, we
> > use
> > it in Debian and Ubuntu for the reasons you mentioned.
> > 
> > And if it's not been translated yet, I agree it's an important one.
> > 
> 
> No, it's not translated yet - mainly for the reasons that I had
> forgotten
> it existed, and that there is a lot yet unported.
> 
> General question: should this be the default or not? It looks to me
> that
> it should probably be, but what do others think?
> 
> /Bruce

Well, to maintain backward compatibility, you might not want to have it
on by default - it's the equivalent of declaring all ABIs compatibility
broken on all releases, some users might not like that.

For us distro maintainers it's very easy to enable.

But I don't have a strong opinion either way - just thinking about
consequences for others.

-- 
Kind regards,
Luca Boccassi


More information about the dev mailing list