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 <tho...@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/98cbd80474fa8b44bf855df32c47dc35e9f...@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
