From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id D7B67A045E for ; Thu, 30 May 2019 15:30:34 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5EE3C493D; Thu, 30 May 2019 15:30:33 +0200 (CEST) Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by dpdk.org (Postfix) with ESMTP id C17CF37A2 for ; Thu, 30 May 2019 15:30:31 +0200 (CEST) Received: by mail-wr1-f65.google.com with SMTP id b18so4194772wrq.12 for ; Thu, 30 May 2019 06:30:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:user-agent:mime-version; bh=uV1B3eO/poz2cGhuN6CmJ9Rk8AiufrcU8pqgTniFpII=; b=Jjbra2/wMIssNBvtZ+WJWBlLPsbAF4a4w1Tj8ckx904VnHgImvie/KWJ1Y+AMsVPE8 Hs/Xy0nP2R9OGGlFE5rIdSZUch0iM4TN8x6FOARrJQToy+WEuNcOMFoe/HKIC6XL54Iz KIBIFgbwB7amdByGU/agYyOHWFD7I1Zz/nH1EHBt/56GxiedcSTZDJH7MWHOevXy1lYd daeeAcp9jkon96ttDKTUdIdII1iqXrDQgZNuueQ6xerm22kBRtQ3e/5esgr2jYohXZiP DoGNgRaGQ7XDwjQ+uC8vZTpyBpzOlOiBfMLbp/zL4uvwYFtCGlvDbAwiSHITcRtPcgEW tFZQ== X-Gm-Message-State: APjAAAUT/rPCwca9aAWvVgyfHw4HckLYpNXXXlmYK3E0oZjQEJhh4o07 iUVIt9YnsbQTacwIsh/s2zQ= X-Google-Smtp-Source: APXvYqyeBNyzQJkCTESBfB50VbTEwWabA4b7DlSb0yKPN+IvJtbm1gvUIQht4wYrLhbH4o1ZX3ZJPA== X-Received: by 2002:adf:9dd2:: with SMTP id q18mr2808072wre.50.1559223031269; Thu, 30 May 2019 06:30:31 -0700 (PDT) Received: from localhost ([88.98.246.218]) by smtp.gmail.com with ESMTPSA id c11sm1784538wrs.97.2019.05.30.06.30.29 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 30 May 2019 06:30:29 -0700 (PDT) Message-ID: <257e37e8b3c24f4523e9d3b90f3eef28076a5d41.camel@debian.org> From: Luca Boccassi To: Ilya Maximets , dev@dpdk.org, Thomas Monjalon Cc: Bruce Richardson , Aaron Conole , Kevin Traynor Date: Thu, 30 May 2019 14:30:29 +0100 In-Reply-To: References: <20190529163958.30796-1-i.maximets@samsung.com> <20190529163958.30796-3-i.maximets@samsung.com> <1a07d1cd59d84dce84e56c10fdabf5e5504560a6.camel@debian.org> <0cc060dc-36e6-88ea-491e-e3b9c552bd7a@samsung.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.30.5-1 MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 2/2] meson: make build configurable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Thu, 2019-05-30 at 14:59 +0300, Ilya Maximets wrote: > On 30.05.2019 14:06, Luca Boccassi wrote: > > On Thu, 2019-05-30 at 13:03 +0300, Ilya Maximets wrote: > > > On 29.05.2019 23:37, Luca Boccassi wrote: > > > > On Wed, 2019-05-29 at 19:39 +0300, Ilya Maximets wrote: > > > > > The first thing many developers do before start building DPDK > > > > > is > > > > > disabling all the not needed divers and libraries. This > > > > > happens > > > > > just because more than a half of DPDK dirvers and libraries > > > > > are > > > > > not > > > > > needed for the particular reason. For example, you don't need > > > > > dpaa*, octeon*, various croypto devices, eventdev, etc. if > > > > > you're > > > > > only want to build OVS for x86_64 with static linking. > > > > >=20 > > > > > By disabling everything you don't need, build speeds up > > > > > literally > > > > > 10x > > > > > times. This is important for CI systems. For example, > > > > > TravisCI > > > > > wastes > > > > > 10 minutes for the default DPDK build just to check linking > > > > > with > > > > > OVS. > > > > >=20 > > > > > Another thing is the binary size. Number of DPDK libraries > > > > > and, > > > > > as a result, size of resulted statically linked application > > > > > decreases > > > > > significantly. > > > > >=20 > > > > > Important thing also that you're able to not install some > > > > > dependencies > > > > > if you don't have them on a target platform. Just disable > > > > > libs/drivers > > > > > that depends on it. Similar thing for the glibc version > > > > > mismatch > > > > > between build and target platforms. > > > > >=20 > > > > > Also, I have to note that less code means less probability of > > > > > failures and less number of attack vectors. > > > > >=20 > > > > > This patch gives 'meson' the power of configurability that we > > > > > have with 'make'. Using new options it's possible to enable > > > > > just > > > > > what you need and nothing more. > > > > >=20 > > > > > For example, following cmdline could be used to build almost > > > > > minimal > > > > > set of DPDK libs and drivers to check OVS build: > > > > >=20 > > > > > $ meson build -Dexamples=3D'' -Dtests=3Dfalse > > > > > -Denable_kmods=3Dfalse > > > > > \ > > > > > -Ddrivers_bus=3Dpci,vdev \ > > > > > -Ddrivers_mempool=3Dring \ > > > > > -Ddrivers_net=3Dnull,virtio,ring \ > > > > > -Ddrivers_crypto=3Dvirtio \ > > > > > -Ddrivers_compress=3Dnone \ > > > > > -Ddrivers_event=3Dnone \ > > > > > -Ddrivers_baseband=3Dnone \ > > > > > -Ddrivers_raw=3Dnone \ > > > > > -Ddrivers_common=3Dnone \ > > > > > =20 > > > > > -Dlibs=3Dkvargs,eal,cmdline,ring,mempool,mbuf,net,meter,\ > > > > > ethdev,pci,hash,cryptodev,pdump,vhost > > > > > \ > > > > > -Dapps=3Dnone > > > > >=20 > > > > > Adding a few real net drivers will give configuration that > > > > > can be > > > > > used > > > > > in production environment. > > > > >=20 > > > > > Looks not very pretty, but this could be moved to a script. > > > > >=20 > > > > > Build details: > > > > >=20 > > > > > Build targets in project: 57 > > > > >=20 > > > > > $ time ninja > > > > > real 0m11,528s > > > > > user 1m4,137s > > > > > sys 0m4,935s > > > > >=20 > > > > > $ du -sh ../dpdk_meson_install/ > > > > > 3,5M ../dpdk_meson_install/ > > > > >=20 > > > > > To compare with what we have without these options: > > > > >=20 > > > > > $ meson build -Dexamples=3D'' -Dtests=3Dfalse > > > > > -Denable_kmods=3Dfalse > > > > > Build targets in project: 434 > > > > >=20 > > > > > $ time ninja > > > > > real 1m38,963s > > > > > user 10m18,624s > > > > > sys 0m45,478s > > > > >=20 > > > > > $ du -sh ../dpdk_meson_install/ > > > > > 27M ../dpdk_meson_install/ > > > > >=20 > > > > > 10x speed up for the user time. > > > > > 7.7 times size decrease. > > > > >=20 > > > > > This is probably not much user-friendly because it's not a > > > > > Kconfig > > > > > and dependency tracking in meson is really poor, so it > > > > > requires > > > > > usually few iterations to pick correct set of libraries to > > > > > satisfy > > > > > all dependencies. However, it's not a big deal. Options > > > > > intended > > > > > for a proficient users who knows what they need. > > > >=20 > > > > Hi, > > > >=20 > > > > We talked about this a few times in the past, and it was > > > > actually > > > > one > > > > of the design goals to _avoid_ replicating the octopus-like > > > > config > > > > system of the makefiles. That's because it makes the test > > > > matrix > > > > insanely complicated, not to mention the harm to user > > > > friendliness, > > > > among other things. > > > >=20 > > > > If someone doesn't want to use a PMD, they can just avoid > > > > installing it > > > > - it's simple enough. > > >=20 > > > So how can I do this? I don't think 'ninja install' has such > > > option. > > > Also, if you think that it is safe to skip some libs/drivers in > > > installation > > > process, it must be safe to not build them at all. It's just a > > > waste > > > of > > > time and computational resources to build something known to be > > > not > > > used. > > > And if you're going to ship DPDK libraries separately in distros, > > > you'll > > > have to test their different combinations anyway. If they're so > > > independent > > > that you don't need to test them in various combinations, than > > > your > > > point > > > about test matrix is not valid. > >=20 > > It can be done in the packaging step, or post-install if there's no > > packaging. An operating system vendor is free to do its own test > > and > > support plan, and decide to leave out some PMDs from it. >=20 > This technically means doing this manually/write custom scripts. It's a standard part of packaging software, both in RPM and DEB - not too familiar with AUR, but I suspect it's not too different in that regard. > > Canonical does > > something similar: in Debian/Ubuntu and derivatives we package PMDs > > individually, and then Canonical groups them in 2 sets - a subset > > they > > guarantee to support from their own resources, and the full set as > > delivered by the community. But the point is that it's a step that > > they > > decide to take, and pay the price for it in terms of time > > investment in > > validating that particular combination, rather than the onus being > > on > > our very limited and already stretched resources to validate all > > combinations. > >=20 > > We can focus our resources into making sure the few combinations > > that > > _must_ be supported, for example due to external dependencies, work > > fine. > >=20 > > > > Sorry, but from me it's a very strong NACK. > > >=20 > > > Sorry, but let me disagree with you. For me, meson > > > configurability is > > > the > > > essential thing to have in terms of deprecating the 'make' build > > > system. > > > DPDK was and keeps being (in most cases) the library that users > > > statically > > > linking to a single application built for particular platform and > > > not > > > using > > > for anything else. This means that user in most cases knows which > > > parts > > > needed and which parts will never be used. Current meson build > > > system > > > doesn't allow to disable anything forcing users to link with the > > > whole bunch > > > of unused code. > > >=20 > > > One major case is that you have to have build environment equal > > > to > > > your > > > target platform in terms of availability of external libraries. > > > So, > > > if I > > > have some external library on build system, meson will build all > > > the > > > modules > > > it depends from and will link them to my application. As a result > > > I'll not > > > be able to run my application on a target platform without > > > installing > > > additional dependencies which is not acceptable. This patch will > > > allow to > > > specifically disable all the libs that has unsatisfiable > > > dependencies > > > on > > > target. Without the patch it's required to manually remove > > > resulted > > > libs and > > > fix pkg-config and stuff before building apps. This is far less > > > user- > > > friendly > > > than options I proposed. And yes, I still have to waste time for > > > building > > > libraries I'll remove right after. > > >=20 > > > While testing OVS on TravisCI, DPDK was built far more than 30K > > > times > > > which is more than half of a year of a wasted computational > > > resources > > > (if we'll count 10 minutes per build). > > > I think this time could be used more wisely. > > >=20 > > > Best regards, Ilya Maximets. > >=20 > > But that's the thing: as it was discussed recently, we need to move > > away from DPDK being by default a "special sauce" toolkit with > > millions > > of customizations that is custom built and statically linked, like > > busybox, and to a situation where it's just another set of system > > libraries like any other, shipped by the operating system, like > > glibc - > > see the threads about stable API/ABI and OS-driven delivery by Ray. > > The status quo of an insanely granular build configuration that > > means > > everyone is using something different from each other is a bug - > > not a > > feature. Excessive _build time_ configuration exacerbates and > > encourages this bug. > >=20 > > Sure, an initial build from scratch will take a couple of minutes > > more > > - mildly annoying, but worth the price. Caching takes care of that > > problem already pretty well. Also standardizing on radically fewer > > build configurations means you _don't_ have to rebuild DPDK for > > third > > party testing - you just consume the pre-built binaries from the OS > > of > > choice, or the PPA or similar for backports and HEAD builds. That > > will > > save even more time and resources in third-party build systems. > >=20 >=20 > CI systems usually build everything from scratch. So caching doesn't > help. > And I don't think that distros will have any pre-built binaries for > the > old systems used in public CI systems. For example, TravisCI has > 'Trusty' > as a default environment. At most you may use 'Xenial'. But I don't > think > that DPDK 18.11 will ever be packaged for them. Also, distros mostly > has > dynamic libraries in their packages not providing static ones. It > might > be changed in the future, but still we'll not have them for 'xenial'. >=20 > So, OVS will stuck with slow building DPDK each time from scratch on > Travis. > And developers will maintain local patches for meson for stripping > extra > libraries or local build scripts that will package only what they > need. >=20 > Best regards, Ilya Maximets. Well, I'm not sure most CI systems build everything from scratch, and even if they do, ccache is supported natively on Travis and others - we use it for DPDK's Travis config, for example. I've yet to see a Travis configuration that rebuilds the kernel, glibc, compiler and every single other dependency of a project from scratch every time, though :- ) In fact, Travis has native support for APT repositories and even PPAs to do the opposite, and it's quite popular as far as I know. Making a PPA or a project on OBS available with repositories for older LTS releases is not only possible, but we already do it today - it's based mostly on request, so for example even though Xenial shipped with DPDk 2.2, a 17.11 PPA is available and maintained already, and I'm sure if we ask very nicely 18.11 can be made available too :-) I'm not sure about the RPM world, but in Debian, Ubuntu and derivatives we ship both static and dynamic libraries by default, and that includes DPDK from day 1. So I can assure you I simpathize with the idea of making CIs faster, and there are many ways to achieve that, that don't require manually hacking the dependencies. For example, I've set up the ZeroMQ CI so that all dependencies from the project and backports for Xenial are built on OBS just as they would be built by the distro, with no compromises or local just-in-time "hacks" to speed up individual builds, so that binary packages are available and installed by Travis via APT on each build. That takes less than 30s regardless of the number of packages (within reason), so whatever we add as a dependency it's still the same. I had done that even for Trusty and Pristine at the time: https://build.opensuse.org/project/monitor/network:messaging:zeromq:git-sta= ble?arch_x86_64=3D1&defaults=3D0&repo_xUbuntu_14_04=3D1&succeeded=3D1 https://build.opensuse.org/project/monitor/network:messaging:zeromq:git-sta= ble?arch_x86_64=3D1&defaults=3D0&repo_xUbuntu_12_04=3D1&succeeded=3D1 Here's a CI job that uses the Trusty repository: https://travis-ci.org/zeromq/czmq/jobs/538626364 --=20 Kind regards, Luca Boccassi