From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 230A7A0555; Fri, 26 Aug 2022 13:33:15 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B29ED40696; Fri, 26 Aug 2022 13:33:14 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 2C8D140143; Fri, 26 Aug 2022 13:33:13 +0200 (CEST) Content-class: urn:content-classes:message Subject: RE: The EAL is bloated MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Aug 2022 13:33:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D872BC@smartserver.smartshare.dk> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: The EAL is bloated Thread-Index: Adi5ORjo/C0MWmaFSm2nLRSUMQXlSQAARkog References: <98CBD80474FA8B44BF855DF32C47DC35D872B5@smartserver.smartshare.dk> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Bruce Richardson" Cc: "Thomas Monjalon" , "David Marchand" , "Ray Kinsella" , "Jerin Jacob" , "Sunil Kumar Kori" , "Harry van Haaren" , , X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org > From: Bruce Richardson [mailto:bruce.richardson@intel.com] > Sent: Friday, 26 August 2022 12.46 >=20 > On Fri, Aug 26, 2022 at 10:58:15AM +0200, Morten Br=F8rup wrote: > > Dear all, > > > > 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! > > > > 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. >=20 > 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 >=20 > 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. >=20 > Regards, > /Bruce