DPDK libs as one big shared object

[Bruce Richardson]

On Thu, Jun 26, 2025 at 05:16:10PM +0200, Thomas Monjalon wrote:
> 26/06/2025 14:53, Stephen Hemminger:
> > On Wed, 18 Jun 2025 12:01:45 +0200
> > Thomas Monjalon <thomas at monjalon.net> wrote:
> > 
> > > 18/06/2025 09:39, Morten Brørup:
> > > > > Why are we still building one .so file per DPDK library, instead of just
> > > > > building one big dpdk.so for all DPDK libraries?
> > > > > I think it's legacy from when DPDK libraries were versioned individually, and
> > > > > thus not relevant anymore.  
> > > 
> > > I think it helps with selective packaging.
> > 
> > That only impacts disk space. The linker is able to only load what is needed at
> > run time. It was a choice made in the build process. Not sure if was the right one
> > most other projects don't have so many libraries to worry about.
> > 
> > > 
> > > 
> > > > > Wouldn't building one big dpdk.so eliminate the problems with circular
> > > > > dependencies between DPDK libraries? 
> > 
> > Yes is why most of the big Gnome and KDE libs are all one shared object.
> >  
> > > > 
> > > > Obviously, the source code should remain organized as individual directories per library.
> > > > I'm only suggesting linking them all into one object, so any DPDK lib can call any function in any other DPDK lib.
> > > > 
> > > > Perhaps only the core libs or always_enable libs should be linked into one object.
> > > > 
> > > > Here's an example benefit:
> > > > I'm currently trying to convince the PMU lib author to make PMU depend on EAL [1], so missing error handling of sysconf(_SC_PAGESIZE) can be in the EAL for all uses, instead of copy-pasting sysconf(_SC_PAGESIZE) error handling to everywhere it is used.
> > > > But this is difficult with the dependency chain for the patch adding PMU to Trace: Trace depends on PMU, and EAL depends on Trace, therefore EAL depends on PMU.
> > > > 
> > > > [1]: https://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35E9FD08@smartserver.smartshare.dk/  
> > > 
> > > I don't see a problem to copy-paste in the few libs not depending on EAL.
> > > 
> > > The real solution for EAL dependencies is to split it more.
> > > The malloc, init & logic part should be in separate libraries,
> > > depending on the real low-level EAL.
> > > 
> > > Then all libs could depend on the low-level EAL,
> > > and avoid copy-pasting.
> > 
> > There have always been two overlapping targets.
> > Embedded standalone and standalone network appliance , where building more than is needed is a nuisance.
> > And distributions which need to turn on everything
> 
> I heard distributions want to be able to not package some parts.
> 

I believe the intention is to only bundle up the mandatory parts of DPDK,
e.g. EAL and dependencies + maybe mempool or a few other libs.
In that case, there should be no option to drop some parts.

/Bruce