26/08/2022 13:33, Morten Brørup: > > From: Bruce Richardson [mailto:bruce.richard...@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
