From: Bruce Richardson <bruce.richardson@intel.com>
To: "Morten Brørup" <mb@smartsharesystems.com>
Cc: <dev@dpdk.org>
Subject: Re: [PATCH 24.03 v2] build: track mandatory rather than optional libs
Date: Fri, 3 Nov 2023 18:08:39 +0000 [thread overview]
Message-ID: <ZUU3J42bfYyMwAjn@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35E9EFCF@smartserver.smartshare.dk>
On Fri, Nov 03, 2023 at 06:31:30PM +0100, Morten Brørup wrote:
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Friday, 3 November 2023 17.52
> >
> > DPDK now has more optional libraries than mandatory ones, so invert the
> > list stored in the meson.build file from the optional ones to the
> > "always_enable" ones. As well as being a shorter list:
> >
> > * we can remove the loop building up the "always_enable" list
> > dynamically from the optional list
> > * it better aligns with the drivers/meson.build file which maintains an
> > always_enable list.
> >
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
>
> Excellent!
>
> It really shows how bloated DPDK CORE still is. I would like to see these go optional:
>
For some I agree, but we need to decide what optional really means. :-)
For my mind, there are 3 (maybe 4) key components that need to be built for
me to consider a build to be a valid DPDK one:
* EAL obviously,
* testpmd, because everyone seems to use it
* l3fwd, becaues it's the most commonly referenced example and used for
benchmarking, and build testing in test-meson-builds. (There are others,
but they are pretty likely to build if l3fwd does!)
* dpdk-test - I feel this should always be buildable, but for me it's the
optional 4th component.
Now, the obviously one to relax here is l3fwd, since it is just an example,
but I wonder if that may cause some heartache.
Anyway some notes:
> acl - OPTIONAL
Used by l3fwd
> cmdline - OPTIONAL (if not used by EAL)
I'd consider this core - used by testpmd and the auto-tests. I'd push this
down the list to consider making optional.
> eal - CORE
> ethdev - CORE, or OPTIONAL for secondary process
Is there really much use of DPDK without ethdev? Let's just keep core for
now.
> fib - OPTIONAL
Used by l3fwd
> hash - OPTIONAL (if not used by CORE libs)
Needed by l3fwd. Also listed as a dependency by a number of drivers, e.g.
i40e, mlx5, nfp, tap. I think they use it for holding filters and things.
This I'd be wary about allowing disabling without some work, as it could
cause users surprise when some drivers unexpectedly stop building.
> kvargs - OPTIONAL (if not used by EAL)
Used by EAL
> log - CORE
> lpm - OPTIONAL
Used by l3fwd
> mbuf - CORE
> mempool - CORE
> meter - OPTIONAL
Used by ethdev.
> net - CORE
> pci - CORE, or OPTIONAL for secondary process
> rcu - OPTIONAL (if not used by CORE libs)
Used by lpm and hash, which are used by l3fwd.
> rib - OPTIONAL
Used by fib, used by l3fwd.
> ring - CORE
Actually, this is one I'd look to maybe say optional. :-)
I think we should switch our default mempool backend from ring to stack,
and make that mandatory. The reason being that run-to-completion apps
should be running entirely out of mempool cache and not care about the
underlying driver, while pipelined apps pushing buffers across cores would
be better with a LIFO-based rather than FIFO-based mempool driver.
Therefore, I think overall switching to stack from ring would be an overall
win for performance.
> stack - OPTIONAL (if not used by CORE libs)
For reasons above, I'd make this core.
> telemetry - OPTIONAL
Used by EAL
> timer - OPTIONAL (if not used by CORE libs)
Only lib that seems to depend on this is eventdev, so maybe this can be an
easy removal. Though I do see it listed as a dependency of ENA driver too.
>
> Anyway,
>
> Acked-by: Morten Brørup <mb@smartsharesystems.com>
>
Overall, if we want to make more libs optional, I would start looking at
l3fwd and making it a bit more modular. I previously made its support for
eventdev optional, we should do the same for lpm and fib. Beyond that, we
need to decide what core really means.
/Bruce
next prev parent reply other threads:[~2023-11-03 18:08 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-03 16:28 [PATCH 24.03] " Bruce Richardson
2023-11-03 16:52 ` [PATCH 24.03 v2] " Bruce Richardson
2023-11-03 17:31 ` Morten Brørup
2023-11-03 18:08 ` Bruce Richardson [this message]
2023-11-03 20:19 ` Morten Brørup
2023-11-06 10:28 ` Bruce Richardson
2023-11-06 11:22 ` Morten Brørup
2023-11-06 11:27 ` Bruce Richardson
2023-11-06 11:37 ` Morten Brørup
2023-12-20 14:21 ` [PATCH v3 0/3] Improve optional lib support Bruce Richardson
2023-12-20 14:21 ` [PATCH v3 1/3] build: track mandatory rather than optional libs Bruce Richardson
2023-12-20 14:21 ` [PATCH v3 2/3] build: remove 5 libs from mandatory list Bruce Richardson
2023-12-20 15:18 ` Morten Brørup
2023-12-20 16:05 ` Bruce Richardson
2023-12-20 14:21 ` [PATCH v3 3/3] build: RFC - add support for optional dependencies Bruce Richardson
2023-12-20 15:08 ` Morten Brørup
2023-12-20 15:43 ` Bruce Richardson
2024-02-01 9:23 ` [PATCH v3 0/3] Improve optional lib support David Marchand
2024-02-01 9:25 ` 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=ZUU3J42bfYyMwAjn@bricha3-MOBL.ger.corp.intel.com \
--to=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=mb@smartsharesystems.com \
/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).