From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id A4EA7A04A6; Fri, 7 Jan 2022 17:47:47 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 284444014F; Fri, 7 Jan 2022 17:47:47 +0100 (CET) Received: from mail-pj1-f49.google.com (mail-pj1-f49.google.com [209.85.216.49]) by mails.dpdk.org (Postfix) with ESMTP id 7269640042 for ; Fri, 7 Jan 2022 17:47:45 +0100 (CET) Received: by mail-pj1-f49.google.com with SMTP id lr15-20020a17090b4b8f00b001b19671cbebso6924140pjb.1 for ; Fri, 07 Jan 2022 08:47:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=TDdmW9Ke9LYgs8h7WvPBkYRUk/xF/ctPS212FAnf6J4=; b=Qpja2bQ2rlcOMOnQpb5qDR1485CR3i45RH/H+vEFkeFruY72/gUbwqxevU1+2bpKx0 8Hm5LP4YyE1G5CSacD5KqdHd83Iue5bkYeg5D97duIUi5l99LnZaLA9Ew7237KV5GIyd sThlP8o8nEZdK8q9AaUyHb3ii/zanH0Rxtb3fXd6XiFQJBl6TeneT1DE0fuHSNivu3o+ NoYYlN9WEaiDdlAGKCWvnNyceftNc4aZL0nWgPUDLkX9SjYLxm7ohlBMDfD7232SwyQl tRFvWLx3jm5nMEensh1GecU+S3TRA/HHKGlEAr4svvKg9rdSDBKbe3dhbo50/IV9uz1k VW4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=TDdmW9Ke9LYgs8h7WvPBkYRUk/xF/ctPS212FAnf6J4=; b=OXWJ/Unc5yQWnk+JKLS4XytJqaA0OY6kakcM/nyGP7FBs+OwS6XdM5p+FP3yNbcIV5 bgN39ywbdlkC0oXRLFOCrqV0Sp+PID9aKCcm31ab/cJY5Km5fm8lA/Rjojr3ve2m/kcY 3AYprT5/vghy5+HcN4Ol7FAjeYDy7jRNwxbjy5CZpYd3L2ziDKemKaRIR5oHe79lcRBS J+bL+Y5+K7gj6QV5lFdju/pV212M7YkdveaXzgoYBpholRxzip9YoUf1nn0S5HEe6tfj 1PROdWl/tARYJj0kcWDSAzaRy2S9e9+VO4IHwqWFUmmE+z3OxANKzp2BgVDW5pMduhPw 81nw== X-Gm-Message-State: AOAM531/4d46PXlpeJz18G2pyS1dg74zbgXLYAU7h55qOoBNAtOhbMry Hdt+Y9oB3SmFzsWF2kMB5SPkdA== X-Google-Smtp-Source: ABdhPJzgC3Q3BAT/ComwW8SjMWYL/5tfQVFzT4RHzbam37UITmzpgXliNwPrE0G1a59dhze9fOmUVg== X-Received: by 2002:a17:902:d50b:b0:149:23d5:fe7a with SMTP id b11-20020a170902d50b00b0014923d5fe7amr63327733plg.92.1641574064495; Fri, 07 Jan 2022 08:47:44 -0800 (PST) Received: from hermes.local (204-195-112-199.wavecable.com. [204.195.112.199]) by smtp.gmail.com with ESMTPSA id q21sm6535603pfu.176.2022.01.07.08.47.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Jan 2022 08:47:44 -0800 (PST) Date: Fri, 7 Jan 2022 08:47:41 -0800 From: Stephen Hemminger To: Morten =?UTF-8?B?QnLDuHJ1cA==?= Cc: "David Marchand" , "Bruce Richardson" , "Thomas Monjalon" , "dev" , "Luca Boccassi" , "Timothy Redaelli" , "Ilya Maximets" , "Jim Harris" , Subject: Re: [PATCH 5/5] build: select optional libraries Message-ID: <20220107084741.01958157@hermes.local> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D86DED@smartserver.smartshare.dk> References: <20211110164814.5231-1-david.marchand@redhat.com> <20211110164814.5231-6-david.marchand@redhat.com> <4536860.m2YTRCI3sh@thomas> <98CBD80474FA8B44BF855DF32C47DC35D86DED@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Fri, 7 Jan 2022 17:13:04 +0100 Morten Br=C3=B8rup wrote: > > From: David Marchand [mailto:david.marchand@redhat.com] > > Sent: Wednesday, 17 November 2021 12.27 > >=20 > > On Wed, Nov 17, 2021 at 11:47 AM Bruce Richardson > > wrote: =20 > > > > > > On Tue, Nov 16, 2021 at 06:25:28PM +0100, Thomas Monjalon wrote: =20 > > > > 10/11/2021 18:34, Bruce Richardson: =20 > > > > > On Wed, Nov 10, 2021 at 05:48:14PM +0100, David Marchand wrote: = =20 > > > > > > There is currently no way to know which libraries are optional. > > > > > > Introduce a enable_libs option (close to what we have for =20 > > drivers) so =20 > > > > > > that packagers or projects consuming DPDK can more easily =20 > > select the =20 > > > > > > optional libraries that matter to them and disable other =20 > > optional =20 > > > > > > libraries. > > > > > > > > > > > > Note: the enabled_libs variable is renamed for sake of =20 > > consistency. =20 > > > > > > > > > > > > Signed-off-by: David Marchand > > > > > > --- =20 > > > > > This is the only patch of this set I would have some concerns =20 > > about. I'm =20 > > > > > just not sure that it makes sense to have this option for =20 > > libraries =20 > > > > > compared to drivers. > > > > > > > > > > Specifically: > > > > > * We have over 200 drivers in DPDK (rough count using find), of = =20 > > which 2 are =20 > > > > > mandatory, and therefore specifying just 1 or 2 that you want = =20 > > can make =20 > > > > > sense. > > > > > * On the other hand, we have 53 libraries, of which only 7 or so = =20 > > (after =20 > > > > > this patchset) are optional. This means that use of the term > > > > > "enable_libs" is misleading - at least to me - in that it's =20 > > only a very =20 > > > > > small proportion of the libs which would be affected by that =20 > > flag =20 > > > > > (compared to 99% of the drivers) =20 > > > > > > > > The options are described like this: > > > > > > > > option('disable_libs', type: 'string', value: '', description: > > > > 'Comma-separated list of libraries to explicitly disable. =20 > > [NOTE: not all libs can be disabled]') =20 > > > > +option('enable_libs', type: 'string', value: '', description: > > > > + 'Comma-separated list of libraries to explicitly enable.') > > > > > > > > I feel we should mention it is enabling optional libraries, > > > > and the default is to enable all. > > > > =20 > > > > > * Also, while the number of mandatory drivers is unlikely to =20 > > change much =20 > > > > > (since there are only 2), it should be fairly safe to do builds= =20 > > using =20 > > > > > "--enable-drivers". On the other hand, the list of libraries =20 > > affected by =20 > > > > > "--enable-libs" is likely to change, so short of each user =20 > > naming each =20 > > > > > and every lib they use (and each library those depend on), to = =20 > > the list, =20 > > > > > it's quite possible that any --enable-libs use could lead to a = =20 > > broken =20 > > > > > build in future if a library changes from mandatory to =20 > > optional. =20 > > > > > > > > In order to be safe, the user can list all required libs, > > > > including non-optional ones. > > > > =20 > > > > > > Yes, they can, but that is the part I'm concerned about. It should =20 > > not be =20 > > > expected for users to know what all libraries should be needed and > > > dependencies between them. The list of mandatory libraries is quite = =20 > > long. =20 > > > =20 > > > > > Overall, I'm just concerned that this flag is premature, and =20 > > would prefer =20 > > > > > to keep it just to the disable option until we are confident that= =20 > > out =20 > > > > > "optional library" list is relatively settled. =20 > > > > > > > > I see it the opposite way: > > > > Someone who does not wish to deliver extra libs could use this =20 > > option =20 > > > > to list the required libs, so not-required libs will disappear from > > > > the build once they are declared optional in future releases. > > > > =20 > > > > > > Yes, though as-above, I'm concerned about the difficulty of building = =20 > > up =20 > > > such a list. However, if this option is only for "expert" and > > > distro-packaging use, then I suppose it's reasonable. Perhaps we =20 > > should add =20 > > > a warning to the doc line too, noting that it's only recommended for > > > advanced users. > > > =20 > >=20 > > Ok, we still need some discussion. > > I'll just respin for Thomas to merge patches that are ready. =20 >=20 > This patch is a step in the right direction. Thank you. >=20 > Adding my opinion to the discussion will be a long rant from a grumpy old= minimalist (working on dedicated network appliances, not Linux distros), s= o here goes: >=20 > The goal should be making all non-core libraries optional. And off the to= p of my head, these are the only core libraries: > EAL, mbuf, mempool, ring. >=20 > And yes, that also means that not even the simplest example applications = can compile with only the core libraries. However, the ability to build a m= inimal dpdk.so should not depend on what is required to be able to build an= y example applications. In other words: If an example application cannot be= built due to an omitted library, then do not build that application. >=20 > E.g. an Ethernet bridge application does not need any IP or routing libra= ries, so they are not core libraries. >=20 > I consider the mbuf library and the libraries it uses (i.e. mempool and r= ing) core libraries, because the core purpose of DPDK is to provide a data = plane library, and all DPDK data plane application use mbufs. :-) >=20 > BTW, I also consider the ethdev library extremely bloated, with Flow, Met= ering, Traffic Management and ever more being added into one big monolithic= library instead of separate libraries or modules. >=20 Agreed, DPDK has become fat and now requires lots of things like meter and = telemetry to build.