DPDK patches and discussions
 help / color / mirror / Atom feed
From: Marco Varlese <marco.varlese@suse.com>
To: Bruce Richardson <bruce.richardson@intel.com>,
	Luca Boccassi <luca.boccassi@gmail.com>
Cc: dev@dpdk.org, thomas@monjalon.net
Subject: Re: [dpdk-dev] [RFCv2 00/40] Building DPDK with meson and ninja
Date: Fri, 18 Aug 2017 11:17:38 +0200	[thread overview]
Message-ID: <1503047858.3032.10.camel@suse.com> (raw)
In-Reply-To: <1503046350.3032.8.camel@suse.com>

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
> > 
> 

  reply	other threads:[~2017-08-18  9:17 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-14  9:51 Bruce Richardson
2017-08-14  9:51 ` [dpdk-dev] [RFCv2 01/40] build: initial hooks for using meson with DPDK Bruce Richardson
2017-08-14  9:51 ` [dpdk-dev] [RFCv2 02/40] build: create pkg-config file for DPDK Bruce Richardson
2017-08-14  9:51 ` [dpdk-dev] [RFCv2 03/40] build: build linuxapp EAL with meson and ninja Bruce Richardson
2017-08-14  9:51 ` [dpdk-dev] [RFCv2 04/40] build: add EAL support under BSD Bruce Richardson
2017-08-14  9:51 ` [dpdk-dev] [RFCv2 05/40] build: add core libraries to meson build system Bruce Richardson
2017-08-14  9:51 ` [dpdk-dev] [RFCv2 06/40] build: add i40e driver to meson build Bruce Richardson
2017-08-14  9:51 ` [dpdk-dev] [RFCv2 07/40] build: add pmdinfogen to build Bruce Richardson
2017-08-14  9:51 ` [dpdk-dev] [RFCv2 08/40] build: generate list of sources for pmdinfogen Bruce Richardson
2017-08-14  9:51 ` [dpdk-dev] [RFCv2 09/40] build: build i40e driver, including pmdinfo Bruce Richardson
2017-08-14  9:51 ` [dpdk-dev] [RFCv2 10/40] build: install usertools scripts Bruce Richardson
2017-08-14  9:51 ` [dpdk-dev] [RFCv2 11/40] build: simplify generation of pmd.c files Bruce Richardson
2017-08-14  9:51 ` [dpdk-dev] [RFCv2 12/40] build: generalize net driver build to higher level Bruce Richardson
2017-08-14  9:51 ` [dpdk-dev] [RFCv2 13/40] build: remove hard-coded enablement of vector driver Bruce Richardson
2017-08-14  9:51 ` [dpdk-dev] [RFCv2 14/40] build: add ixgbe driver to build Bruce Richardson
2017-08-14  9:51 ` [dpdk-dev] [RFCv2 15/40] build: set up standard deps for drivers Bruce Richardson
2017-08-14  9:51 ` [dpdk-dev] [RFCv2 16/40] build: add af_packet driver to build Bruce Richardson
2017-08-14  9:51 ` [dpdk-dev] [RFCv2 17/40] build: add pcap PMD support Bruce Richardson
2017-08-14  9:51 ` [dpdk-dev] [RFCv2 18/40] build: add symbol version map file support to libs Bruce Richardson
2017-08-14  9:51 ` [dpdk-dev] [RFCv2 19/40] build: build libraries in a loop for brevity Bruce Richardson
2017-08-14  9:51 ` [dpdk-dev] [RFCv2 20/40] build: version library .so files Bruce Richardson
2017-08-14  9:51 ` [dpdk-dev] [RFCv2 21/40] eal: add version information to meson build Bruce Richardson
2017-08-14  9:51 ` [dpdk-dev] [RFCv2 22/40] build: add mempool drivers to build Bruce Richardson
2017-08-14  9:51 ` [dpdk-dev] [RFCv2 23/40] build: add gro library to meson build Bruce Richardson
2017-08-14  9:51 ` [dpdk-dev] [RFCv2 24/40] build: tweak naming of pmd dependencies Bruce Richardson
2017-08-14  9:51 ` [dpdk-dev] [RFCv2 25/40] build: track driver include directories properly Bruce Richardson
2017-08-14  9:51 ` [dpdk-dev] [RFCv2 26/40] metrics: add metrics lib to meson build Bruce Richardson
2017-08-14  9:51 ` [dpdk-dev] [RFCv2 27/40] build: track dependencies recursively Bruce Richardson
2017-08-14  9:51 ` [dpdk-dev] [RFCv2 28/40] testpmd: compile testpmd with meson and ninja Bruce Richardson
2017-08-14  9:51 ` [dpdk-dev] [RFCv2 29/40] crypto/null: rename the version file to standard Bruce Richardson
2017-08-14  9:51 ` [dpdk-dev] [RFCv2 30/40] crypto/qat: remove dependency on ether library Bruce Richardson
2017-08-14  9:51 ` [dpdk-dev] [RFCv2 31/40] build: add cryptodev and some crypto drivers to build Bruce Richardson
2017-08-14  9:52 ` [dpdk-dev] [RFCv2 32/40] igb_uio: add igb_uio to meson build Bruce Richardson
2017-08-14  9:52 ` [dpdk-dev] [RFCv2 33/40] ip_frag: rename version file to standard name Bruce Richardson
2017-08-14  9:52 ` [dpdk-dev] [RFCv2 34/40] build: add most remaining libraries to meson build Bruce Richardson
2017-08-14  9:52 ` [dpdk-dev] [RFCv2 35/40] build: add packet framework libs " Bruce Richardson
2017-08-14  9:52 ` [dpdk-dev] [RFCv2 36/40] acl: add acl library " Bruce Richardson
2017-08-14  9:52 ` [dpdk-dev] [RFCv2 37/40] build: add ark and avp PMDs to build Bruce Richardson
2017-08-14  9:52 ` [dpdk-dev] [RFCv2 38/40] build: fix static library builds with base code Bruce Richardson
2017-08-14  9:52 ` [dpdk-dev] [RFCv2 39/40] build: fix driver dependencies for static builds Bruce Richardson
2017-08-14  9:52 ` [dpdk-dev] [RFCv2 40/40] examples: allow basic sample app build using pkg-config Bruce Richardson
2017-08-15 10:56 ` [dpdk-dev] [RFCv2 00/40] Building DPDK with meson and ninja Luca Boccassi
2017-08-15 11:31   ` Bruce Richardson
2017-08-17 14:10 ` Marco Varlese
2017-08-17 15:25   ` Luca Boccassi
2017-08-18  8:35     ` Bruce Richardson
2017-08-18  8:52       ` Marco Varlese
2017-08-18  9:17         ` Marco Varlese [this message]
2017-08-18  9:33       ` Luca Boccassi
     [not found]   ` <1502983469.31476.3.camel@gmail.com>
2017-08-18  8:00     ` Marco Varlese

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1503047858.3032.10.camel@suse.com \
    --to=marco.varlese@suse.com \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=luca.boccassi@gmail.com \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).