DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: "Morten Brørup" <mb@smartsharesystems.com>
Cc: Thomas Monjalon <thomas@monjalon.net>,
	David Marchand <david.marchand@redhat.com>,
	Ray Kinsella <mdr@ashroe.eu>, Jerin Jacob <jerinj@marvell.com>,
	Sunil Kumar Kori <skori@marvell.com>,
	Harry van Haaren <harry.van.haaren@intel.com>, <dev@dpdk.org>,
	<techboard@dpdk.org>
Subject: Re: The EAL is bloated
Date: Fri, 26 Aug 2022 11:46:13 +0100	[thread overview]
Message-ID: <Ywikdf7F3vwzU4RS@bricha3-MOBL.ger.corp.intel.com> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D872B5@smartserver.smartshare.dk>

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

  reply	other threads:[~2022-08-26 10:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-26  8:58 Morten Brørup
2022-08-26 10:46 ` Bruce Richardson [this message]
2022-08-26 11:33   ` Morten Brørup
2022-08-26 12:36     ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Ywikdf7F3vwzU4RS@bricha3-MOBL.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=harry.van.haaren@intel.com \
    --cc=jerinj@marvell.com \
    --cc=mb@smartsharesystems.com \
    --cc=mdr@ashroe.eu \
    --cc=skori@marvell.com \
    --cc=techboard@dpdk.org \
    --cc=thomas@monjalon.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).