Re: The EAL is bloated

[Thomas Monjalon <thomas@monjalon.net>]

26/08/2022 13:33, Morten Brørup:
> > From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> > Sent: Friday, 26 August 2022 12.46
> > 
> > On Fri, Aug 26, 2022 at 10:58:15AM +0200, Morten Brørup wrote:
> > > Dear all,
> > >
> > > <rant> The "Environment Abstraction Layer" is expanding far beyond
> > its
> > > purpose...
> > >
> > > It not only includes abstractions for the underlying CPU Arch and
> > O/S,
> > > but also a bunch of generic utility functions. In an ideal world,
> > these
> > > belong in a Utility library; but I can live with them staying in the
> > EAL
> > > library.
> > >
> > > However, since the Utility features are also considered part of the
> > EAL
> > > library, some features get misclassified as Utilities and thus sneak
> > into
> > > the EAL library, regardless that they are completely independent of
> > the
> > > underlying CPU Arch and O/S. E.g.: Service Cores, Trace, and soon the
> > > Lcore Poll Busyness library.
> > >
> > > The EAL is not a catch-all library, and we should not allow the EAL
> > to
> > > grow like this!  </rant>
> > >
> > > If this misbehavior doesn't stop naturally, I propose that adding any
> > new
> > > feature to the EAL requires techboard approval.
> > >
> > I don't disagree with you that it is indeed becoming ever bigger, and
> > that
> > we need to do something to do some cleanup on EAL. However, IMHO this
> > is
> > not a simple problem to fix or even to draft up a solution for. I
> > actually
> > did some prototyping work in the recent past to try and see if or how
> > much
> > the EAL could be split up to make it more modular. On the plus side,
> > some
> > things like logging, for example, could be fairly easily pulled out of
> > it
> > and put into a separate library. On the other hand, really splitting
> > things
> > up beyond pulling out a few easy things was a massive undertaking - at
> > least in my tests.
> > 
> > I also think trying to classify contents between abstractions and
> > utilities
> > is overly simplistic. To my mind we also need to have a category for
> > DPDK
> > initialization code, which is a lot of what complicates things - and
> > may
> > well be the cause of a lot of the "scope creep" in EAL.
> 
> For the initialization code, it should make it easier that DPDK is no longer compiled to a bunch of independent libraries (.so files) with independent versions, but compiled into one big library.
> 
> Regarding libraries that are part of DPDK, e.g. Logging, I don't mind calling their required init functions from the various relevant locations inside the EAL. I assume that the various libraries need to be initialized at different stages throughout EAL, so a single point of "library init callout" in the EAL is not sufficient.
> 
> Some of the DPDK Core libraries, e.g. Mempool and Ring, are outside the EAL; this shows that they don't have to be part of EAL, although a DPDK application without them would be pretty silly.
> 
> Long term, the EAL could also include some hooks or similar, to allow external libraries to be initialized from EAL. The DPDK application startup sequence is well documented [1]; perhaps something can be added to this "power-on sequence" (borrowing a term from the hardware world). For inspiration, C loadable libraries expose an _init() function, which is called when the library is loaded. I don't have a solution to this; just thinking out aloud. The libraries included in DPDK could also use such a generic initialization hooking mechanism, if present.

I have a slightly different view of the init process.
I think rte_eal_init() should be considered a helper.
We could have different helpers doing much more assumptions,
and if we need a different init, the application should be able to write the init sequence entirely.


> [1] https://doc.dpdk.org/guides/prog_guide/env_abstraction_layer.html#eal-in-a-linux-userland-execution-environment
> 
> > 
> > Given the scope of the problem - and the fact that splitting EAL has
> > been
> > discussed before and nothing came of it in the community - I'm not sure
> > of
> > the best approach here. Maybe we can start by splitting out what we can
> > of
> > the easy stuff, and work iteratively from there. Alternatively if
> > someone
> > has time for a big-bang rework of EAL, that would be great too.
> 
> I wish! But I think small steps are more realistic.

I wish too.
We probably need to start somewhere.

> Splitting out the easy parts would be a good start. And it would certainly raise awareness against EAL scope creep.

+1