The EAL is bloated

The EAL is bloated

[Morten Brørup]

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.

-Morten

Re: The EAL is bloated

[Bruce Richardson]

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.

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.

Regards,
/Bruce

RE: The EAL is bloated

[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.

[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.

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

> 
> Regards,
> /Bruce

Re: The EAL is bloated

[Thomas Monjalon]

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