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

Marco Varlese marco.varlese at suse.com
Fri Aug 18 11:17:38 CEST 2017


On Fri, 2017-08-18 at 10:52 +0200, Marco Varlese wrote:
> 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/patch
> > > > > /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?
> I do think it should be the default too. 
And - since you're at it - it would be a good idea to add the versioning to the
built executables (e.g. test_pmd) similarly to what other software (e.g. gcc) do
to make sure you can also have cohexistance of executables. Otherwise, dpdk
executables would be overwritten with subsequent installations.
Does it make sense?

> 
> > 
> > 
> > /Bruce
> > 
> 


More information about the dev mailing list