DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: Mohammed Hawari <mohammed@hawari.fr>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 1/1] build: allow disabling libs
Date: Fri, 18 Sep 2020 12:43:29 +0100
Message-ID: <20200918114329.GA1589@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <20200918084924.31784-2-mohammed@hawari.fr>

On Fri, Sep 18, 2020 at 10:49:23AM +0200, Mohammed Hawari wrote:
> Similarly to the disable_drivers option, the disable_libs option is
> introduced. This allows to selectively disable the build of elements
> in libs to speed-up the build process.
> 
> Signed-off-by: Mohammed Hawari <mohammed@hawari.fr>
> ---

While I don't particularly like allowing libs to be enabled and disabled
since it complicates the build, I can see why it's necessary. This is an
area that does need some discussion, as I believe others have some opinions
in this area too.

However, for now, some additional thoughts, both on this patch and in
general:

1. I see you included disabling apps if their required libs are not
   available. What about the drivers though?
2. A bigger issue is whether this is really what we want to do, guarantee a
   passing build even if vast chunks of DPDK are actually enabled? I'd tend
   towards "no" in this case, and I'd rather see disabling of libs more
   constrained.
3. To this end, I think I'd rather see us maintain a set of libs which are
   allowed to be disabled, and prevent the rest from being so. For example,
   it makes no sense in DPDK to disable the EAL or mempool libs, since nothing
   will build, while the bitrate_stats or latency_stats libs could likely
   be disabled with little or no impact.

Therefore, I think a better implementation is to start as in this patch
with a new config parameter to disable libs, but as part of that patch add
in an internal list of the libs which are allowed to be disabled (initially
empty). Telling the build system to disable a lib not on that list should
raise a configuration time error. As for how a lib gets on the list - that
should be done once the build has been tested with that lib disabled, i.e.
once testpmd and other apps have got #defines in the code for stripping out
the disabled blocks, and any drivers which depend on the lib have proper
checks and warnings in place about it being disabled (or also #defines in
the code if that can be done).

The other advantage of maintaining such a list is that it then becomes
somewhat feasible to test these build settings, in that (maybe once per
release), iterate through the list of disable-able libs and test that the
build passed with each one disabled individually. [I think for this purpose
we can ignore interactions of having two disabled simultaneously, in order
to have something testable]

What do others in the community think?

Regards,
/Bruce

  reply	other threads:[~2020-09-18 11:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-18  8:49 [dpdk-dev] [PATCH 0/1] " Mohammed Hawari
2020-09-18  8:49 ` [dpdk-dev] [PATCH 1/1] " Mohammed Hawari
2020-09-18 11:43   ` Bruce Richardson [this message]
2020-09-18 12:54     ` Mohammed Hawari
2020-09-18 13:57       ` Bruce Richardson

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=20200918114329.GA1589@bricha3-MOBL.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=mohammed@hawari.fr \
    /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

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
		dev@dpdk.org
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.dpdk.org/inbox.dpdk.dev


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git