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 D48CCA0550; Fri, 26 Aug 2022 14:37:04 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id B469540146; Fri, 26 Aug 2022 14:37:04 +0200 (CEST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by mails.dpdk.org (Postfix) with ESMTP id BAEB840143; Fri, 26 Aug 2022 14:37:02 +0200 (CEST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 628AF32009F5; Fri, 26 Aug 2022 08:36:58 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Fri, 26 Aug 2022 08:36:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1661517417; x= 1661603817; bh=coDTNdIKo+JHvY1dv8ceX9m+DiMqDHwtUiCUwiR4gck=; b=m XiQkz/b+pwGWwlKH9PIu0JHP7vRemyZqS11SGf/bc+IpsP1tf/TXlJEvubKvmSYD lp7G93/FKIGlilwQE2l//NTsR3usQvLDpEIn9Zr3EObLFowH2bhlpQhi/uamyZL1 AH4gWgRlgqzrJeZgeJ0FfIWA4ogpyHbJRsrIA0QeDyCfHHwlcT2j2A+hi8OrYje/ eg8OZ3hEb+/XSiEGdiVp2qfxDQGi39fYskJO8p1yVfUBoBT4/+CFAYceC2D7deQR goV6/9P5p5ng24tbHh2Y/UqNmLkwLXOGERSpX6AB/4HaVz7zN0upO4EIeSv8C2Ad crnz0WG/gE04gwV10uHXA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1661517417; x= 1661603817; bh=coDTNdIKo+JHvY1dv8ceX9m+DiMqDHwtUiCUwiR4gck=; b=v pIwb9bDa876gk/elgK/iZLq51UyAoEZh193OAvmQlFfQuI7KDvdBLxKMog6juHfZ gUQlLbeCebmMDez7U3eJlD8mPiJmTo5lEHOwp3WBjnWfwERBUJxOyA/1JwWuZExO 7bXRNPY64837ScJFvcSxGWWgVwSidhaG+msno/eNwyNLL7nhYkM7koMVclObasz9 elF4s8ymrW3qN2Tt8J7XTzRTPPhUIR/GvrqLcAj08KPsB0T/cBDNagkWZgT2a2Sb L2u7p6MBpWrGLlq2imRvfDfJqqEfuMbia4QVU0xng3mHIYOPmU7sYfi4dpYYP8df 7h9eqIrmAWJ8jEwFkrn6g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdejhedghedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthhqredttddtudenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeegjeeivdelheduhfeugfefvefgheeiteegiefggffgffffieeu gfeukedtfeefveenucffohhmrghinhepughpughkrdhorhhgnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhho nhdrnhgvth X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 26 Aug 2022 08:36:56 -0400 (EDT) From: Thomas Monjalon To: Bruce Richardson , Morten =?ISO-8859-1?Q?Br=F8rup?= Cc: David Marchand , Ray Kinsella , Jerin Jacob , Sunil Kumar Kori , Harry van Haaren , dev@dpdk.org, techboard@dpdk.org Subject: Re: The EAL is bloated Date: Fri, 26 Aug 2022 14:36:55 +0200 Message-ID: <2594603.Isy0gbHreE@thomas> In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D872BC@smartserver.smartshare.dk> References: <98CBD80474FA8B44BF855DF32C47DC35D872B5@smartserver.smartshare.dk> <98CBD80474FA8B44BF855DF32C47DC35D872BC@smartserver.smartshare.dk> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" 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 26/08/2022 13:33, Morten Br=F8rup: > > 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. >=20 > For the initialization code, it should make it easier that DPDK is no lon= ger compiled to a bunch of independent libraries (.so files) with independe= nt versions, but compiled into one big library. >=20 > Regarding libraries that are part of DPDK, e.g. Logging, I don't mind cal= ling their required init functions from the various relevant locations insi= de the EAL. I assume that the various libraries need to be initialized at d= ifferent stages throughout EAL, so a single point of "library init callout"= in the EAL is not sufficient. >=20 > Some of the DPDK Core libraries, e.g. Mempool and Ring, are outside the E= AL; this shows that they don't have to be part of EAL, although a DPDK appl= ication without them would be pretty silly. >=20 > Long term, the EAL could also include some hooks or similar, to allow ext= ernal libraries to be initialized from EAL. The DPDK application startup se= quence is well documented [1]; perhaps something can be added to this "powe= r-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= =2E The libraries included in DPDK could also use such a generic initializa= tion 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 th= e init sequence entirely. > [1] https://doc.dpdk.org/guides/prog_guide/env_abstraction_layer.html#eal= =2Din-a-linux-userland-execution-environment >=20 > >=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. >=20 > 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 certainl= y raise awareness against EAL scope creep. +1