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 28D3E42CC7; Thu, 15 Jun 2023 17:44:29 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BCFB140EE3; Thu, 15 Jun 2023 17:44:28 +0200 (CEST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mails.dpdk.org (Postfix) with ESMTP id C75AF40E0F for ; Thu, 15 Jun 2023 17:44:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1686843866; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xNfk+IoXUy11Jk4c+McYuJJaerdhqYYTwR1Us2Hkixw=; b=Xy3le9GxmYnZVM4sCH8ixOyyQJJ9hn5TIr1Fp0JRNU/JLqSWMEgnc4LZ58tjvir8m0gVsc PwLPlEacMbNafzixjOwIjypS3n15R+ud8gQB6VTm1sYUc2MgbZwWDxvwsu6WzFocrAYuWu TVwW+xcz/yizbc3rGfRnWc2zmuD1oxg= Received: from mail-pg1-f200.google.com (mail-pg1-f200.google.com [209.85.215.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-1-8UMeYqgpPI-sqpSZVPxjSQ-1; Thu, 15 Jun 2023 11:44:18 -0400 X-MC-Unique: 8UMeYqgpPI-sqpSZVPxjSQ-1 Received: by mail-pg1-f200.google.com with SMTP id 41be03b00d2f7-543a89d0387so3726854a12.1 for ; Thu, 15 Jun 2023 08:44:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686843848; x=1689435848; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=xNfk+IoXUy11Jk4c+McYuJJaerdhqYYTwR1Us2Hkixw=; b=hy2pCkSF2JWSpqWWMP6Xj4hcgknk+cE0cw5C62CizO+rB6KtJF4fLPQBuq0ndTb/kd oWRwNRxWGu3m6urD1UcaaJBgTDn5zVbpEIJmRnRk+18eSXYcBv/VGAjz0y6SAf6wUE9O 7ZJJCyxKnAf0Rg/drasJmZ0N9TFzfqUFjdc7ovAZV+TvMCPqQOKLl7BJ4TqCiuYdmE3c cYHogM5l5Sz8/v+onANzlBVGVoNQ+T3gvVn0Lbta/jKzbnFkwGnW5cxrYgEeynayiYsg 7FKx/lkz++UuFkSVvHLApvvhY/hD2rZDtcpaQWgfmXrX9kwCsHnvUF3RlYFat3QLypB0 70ZQ== X-Gm-Message-State: AC+VfDx9zFLurXB0yGFzx0oK2dOFYpzCh/82jH3xc+pcW4uw4+K0zrAT XriNqyPK7t2Eb9+74jfA6dyqTHWTGASveEGFgrcBUobMrsO0y4NJF7LyGHM9bv1Lv5YwmXRE9+O yFPs93ey018ZGAfT1N3Y= X-Received: by 2002:a17:90a:1903:b0:259:45bc:e6b5 with SMTP id 3-20020a17090a190300b0025945bce6b5mr3804478pjg.44.1686843848400; Thu, 15 Jun 2023 08:44:08 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ69PsxVA++66tlshJtOeq4GWeeMetz7tMD6tjoPItdqzBfIo1c1c08kcQ3RWX45Gk9HbCvQ/MNvVwYRj4bQ5ps= X-Received: by 2002:a17:90a:1903:b0:259:45bc:e6b5 with SMTP id 3-20020a17090a190300b0025945bce6b5mr3804472pjg.44.1686843848121; Thu, 15 Jun 2023 08:44:08 -0700 (PDT) MIME-Version: 1.0 References: <20200918084924.31784-1-mohammed@hawari.fr> <20200918084924.31784-2-mohammed@hawari.fr> <20200918114329.GA1589@bricha3-MOBL.ger.corp.intel.com> <33FE1BDE-C31E-4879-836B-DA22C850B829@hawari.fr> <20200918135750.GA1592@bricha3-MOBL.ger.corp.intel.com> <20230614120945.3e386d16@hermes.local> In-Reply-To: From: David Marchand Date: Thu, 15 Jun 2023 17:43:56 +0200 Message-ID: Subject: Re: [dpdk-dev] [PATCH 1/1] build: allow disabling libs To: Bruce Richardson Cc: Stephen Hemminger , Mohammed Hawari , dev@dpdk.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com 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 Thu, Jun 15, 2023 at 10:43=E2=80=AFAM Bruce Richardson wrote: > > On Wed, Jun 14, 2023 at 12:09:51PM -0700, Stephen Hemminger wrote: > > On Fri, 18 Sep 2020 14:57:50 +0100 > > Bruce Richardson wrote: > > > > > On Fri, Sep 18, 2020 at 02:54:21PM +0200, Mohammed Hawari wrote: > > > > Hello Bruce, > > > > > > > > Thanks for the quick response, see inline > > > > > > > > Best regards, > > > > > > > > Mohammed > > > > > > > > > On 18 Sep 2020, at 13:43, Bruce Richardson wrote: > > > > > > > > > > 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 elem= ents > > > > >> in libs to speed-up the build process. > > > > >> > > > > >> Signed-off-by: Mohammed Hawari > > > > >> --- > > > > > > > > > > While I don't particularly like allowing libs to be enabled and d= isabled > > > > > since it complicates the build, I can see why it's necessary. Thi= s is an > > > > > area that does need some discussion, as I believe others have som= e opinions > > > > > in this area too. > > > > > > > > > > However, for now, some additional thoughts, both on this patch an= d in > > > > > general: > > > > > > > > > > 1. I see you included disabling apps if their required libs are n= ot > > > > > available. What about the drivers though? > > > > To my understanding, in the current code, the drivers/meson.build f= ile already > > > > does that check with: > > > > > > > > foreach d:deps > > > > if not is_variable('shared_rte_' + d) > > > > build =3D false > > > > > > > > > > Yes, my mistake, I forgot that that was added as one driver could dep= end > > > upon another. :-( > > > > > > > > 2. A bigger issue is whether this is really what we want to do, g= uarantee 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, s= ince nothing > > > > > will build, while the bitrate_stats or latency_stats libs could= likely > > > > > be disabled with little or no impact. > > > > I tend to agree with that more structured approach, but I am going = to wait until > > > > we get some more thoughts from the community before starting that w= ork. > > > > > > > > > > That seems a wise approach. If there is no consensus after a while he= re, it > > > probably needs to go to the technical board. > > > > > > Marking current patch as "Changes requested". > > Assume that if someone wants to go further then and propose a more > > targeted build setting. Something like minimal?? > > The more targetted approach has been implemented and can constantly be > improved upon. We can already disable a set of libraries, with only those > validated as being ok to disable on that list. Therefore, I think this > patch can just be rejected as obsolete. Any additional work in this area > should be: > * increasing list of optional libs > * looking again at adding an "enable_libs" flag. I was against this > previously, but now think it's time may have come! I still have my patch on enable_libs that I rebased not too long ago (around the time the iova va build option was touched by Thomas). I could retest it and post it if it helps. --=20 David Marchand