From: Thomas Monjalon <thomas@monjalon.net>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: "Morten Brørup" <mb@smartsharesystems.com>,
dev@dpdk.org, techboard@dpdk.org,
"Tomasz Duszynski" <tduszynski@marvell.com>
Subject: Re: DPDK libs as one big shared object
Date: Thu, 26 Jun 2025 17:16:10 +0200 [thread overview]
Message-ID: <6044178.qgXdJBQaxk@thomas> (raw)
In-Reply-To: <20250626055319.1ef24c96@hermes.local>
26/06/2025 14:53, Stephen Hemminger:
> On Wed, 18 Jun 2025 12:01:45 +0200
> Thomas Monjalon <thomas@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.
next prev parent reply other threads:[~2025-06-26 15:16 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-16 16:14 DPDK libs as one big shared object Morten Brørup
2025-06-18 7:39 ` Morten Brørup
2025-06-18 10:01 ` Thomas Monjalon
2025-06-26 12:53 ` Stephen Hemminger
2025-06-26 15:16 ` Thomas Monjalon [this message]
2025-06-26 16:46 ` 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=6044178.qgXdJBQaxk@thomas \
--to=thomas@monjalon.net \
--cc=dev@dpdk.org \
--cc=mb@smartsharesystems.com \
--cc=stephen@networkplumber.org \
--cc=tduszynski@marvell.com \
--cc=techboard@dpdk.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.