Re: [PATCH 24.03 v2] build: track mandatory rather than optional libs

[Bruce Richardson <bruce.richardson@intel.com>]

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