From: Thomas Monjalon <thomas@monjalon.net>
To: David Marchand <david.marchand@redhat.com>,
Bruce Richardson <bruce.richardson@intel.com>
Cc: dev@dpdk.org, "Morten Brørup" <mb@smartsharesystems.com>,
anatoly.burakov@intel.com, dmitry.kozliuk@gmail.com,
"Tyler Retzlaff" <roretzla@linux.microsoft.com>,
harry.van.haaren@intel.com, jerinj@marvell.com
Subject: Re: [PATCH v8 0/3] Split logging functionality out of EAL
Date: Fri, 01 Sep 2023 13:25:27 +0200 [thread overview]
Message-ID: <8822393.VV5PYv0bhD@thomas> (raw)
In-Reply-To: <ZNYwxqQ9jDS+7Tf0@bricha3-MOBL.ger.corp.intel.com>
11/08/2023 14:59, Bruce Richardson:
> On Fri, Aug 11, 2023 at 02:46:13PM +0200, David Marchand wrote:
> > On Wed, Aug 9, 2023 at 3:36 PM Bruce Richardson
> > <bruce.richardson@intel.com> wrote:
> > >
> > > There is a general desire to reduce the size and scope of EAL. To this
> > > end, this patchset makes a (very) small step in that direction by taking
> > > the logging functionality out of EAL and putting it into its own library
> > > that can be built and maintained separately.
> > >
> > > As with the first RFC for this, the main obstacle is the "fnmatch"
> > > function which is needed by both EAL and the new log function when
> > > building on windows. While the function cannot stay in EAL - or we would
> > > have a circular dependency, moving it to a new library or just putting
> > > it in the log library have the disadvantages that it then "leaks" into
> > > the public namespace without an rte_prefix, which could cause issues.
> > > Since only a single function is involved, subsequent versions take a
> > > different approach to v1, and just moves the offending function to be a
> > > static function in a header file. This allows use by multiple libs
> > > without conflicting names or making it public.
> > >
> > > The other complication, as explained in v1 RFC was that of multiple
> > > implementations for different OS's. This is solved here in the same
> > > way as v1, by including the OS in the name and having meson pick the
> > > correct file for each build. Since only one file is involved, there
> > > seemed little need for replicating EAL's separate subdirectories
> > > per-OS.
> >
> > Series applied, thanks Bruce for this first step.
> >
> > As mentionned during the maintainers weekly call yesterday, this is
> > only a first "easy" step but, thinking of next steps, more splitting
> > may not be that easy.
>
> I took a look after doing this patchset to try and find more easy to
> extract parts, but did not find many. The EAL is pretty intertwined now.
> As I look at it, there are really two ways to try and dis-entangle it -
> bottoms-up or top-down. This patchset is an example of the former, taking a
> logical set of related APIs and pulling them out into a separate library
> that EAL can depend upon. There may be some other API-sets like this we can
> pull out, but in my search I didn't find any.
A small thing to easily separate is rte_bitmap.
> The other tops-down approach may be worth looking at too. We can try and
> take the top-level EAL init function and separate it out into a separate
> initialization library (which may be called "EAL" with the rest being
> called something else). I have not tried this approach to see how it goes,
> but pulling out the init may allow further dis-entangling of other parts of
> EAL.
I agree we should start with separating the init logic.
I would call it rte_init. We may need rte_opts for command line parsing.
I think the name EAL should be kept for the low-level functions,
abstracting differences between OS, CPU and toolchains.
Next steps would be to try to separate memory and CPU management
in 2 different libraries.
We'll need to decide whether rte_service is part of the CPU management.
Same question for multiprocess communication rte_mp and rte_keepalive.
I suppose we can keep IRQ and threading in EAL.
VFIO may be managed in a separate library perhaps.
Once we do that, the low-level libraries like log, kvargs and telemetry
can depend on EAL, being the very low-level common denominator.
The trace subsystem can probably become a separate library as well.
In a later step, we can think about bus and device management.
And the ideal would be to extract tailq, once all logic is out of EAL.
How does it sound?
next prev parent reply other threads:[~2023-09-01 11:25 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-29 15:18 [RFC PATCH 0/3] Split logging " Bruce Richardson
2022-08-29 15:18 ` [RFC PATCH 1/3] os: begin separating some OS compatibility from EAL Bruce Richardson
2022-08-29 18:57 ` Morten Brørup
2022-08-30 8:41 ` Bruce Richardson
2022-08-30 8:42 ` David Marchand
2022-08-30 9:59 ` Bruce Richardson
2022-08-29 15:19 ` [RFC PATCH 2/3] log: separate logging functions out of EAL Bruce Richardson
2022-08-29 15:19 ` [RFC PATCH 3/3] telemetry: use standard logging Bruce Richardson
2023-01-13 16:19 ` [RFC PATCH v2 0/3] Split logging functionality out of EAL Bruce Richardson
2023-01-13 16:19 ` [RFC PATCH v2 1/3] eal/windows: move fnmatch function to header file Bruce Richardson
2023-01-13 16:41 ` Morten Brørup
2023-01-13 17:01 ` Bruce Richardson
2023-01-13 17:31 ` Tyler Retzlaff
2023-01-13 17:37 ` Bruce Richardson
2023-01-13 16:20 ` [RFC PATCH v2 2/3] log: separate logging functions out of EAL Bruce Richardson
2023-01-13 16:20 ` [RFC PATCH v2 3/3] telemetry: use standard logging Bruce Richardson
2023-01-13 20:36 ` [PATCH v3 0/3] Split logging functionality out of EAL Bruce Richardson
2023-01-13 20:36 ` [PATCH v3 1/3] eal/windows: move fnmatch function to header file Bruce Richardson
2023-01-13 20:36 ` [PATCH v3 2/3] log: separate logging functions out of EAL Bruce Richardson
2023-01-13 20:36 ` [PATCH v3 3/3] telemetry: use standard logging Bruce Richardson
2023-01-20 18:21 ` [PATCH v4 0/3] Split logging functionality out of EAL Bruce Richardson
2023-01-20 18:21 ` [PATCH v4 1/3] eal/windows: move fnmatch function to header file Bruce Richardson
2023-01-20 18:21 ` [PATCH v4 2/3] log: separate logging functions out of EAL Bruce Richardson
2023-01-20 18:21 ` [PATCH v4 3/3] telemetry: use standard logging Bruce Richardson
2023-01-22 14:56 ` [PATCH v4 0/3] Split logging functionality out of EAL David Marchand
2023-01-23 14:24 ` Bruce Richardson
2023-01-23 14:31 ` David Marchand
2023-01-23 14:36 ` Bruce Richardson
2023-01-23 14:42 ` David Marchand
2023-05-18 12:49 ` [PATCH v5 " Bruce Richardson
2023-05-18 12:49 ` [PATCH v5 1/3] eal/windows: move fnmatch function to header file Bruce Richardson
2023-05-18 12:49 ` [PATCH v5 2/3] log: separate logging functions out of EAL Bruce Richardson
2023-05-18 12:49 ` [PATCH v5 3/3] telemetry: use standard logging Bruce Richardson
2023-07-31 10:17 ` [PATCH v6 0/3] Split logging functionality out of EAL Bruce Richardson
2023-07-31 10:17 ` [PATCH v6 1/3] eal/windows: move fnmatch function to header file Bruce Richardson
2023-07-31 10:17 ` [PATCH v6 2/3] log: separate logging functions out of EAL Bruce Richardson
2023-07-31 10:17 ` [PATCH v6 3/3] telemetry: use standard logging Bruce Richardson
2023-07-31 15:38 ` [PATCH v7 0/3] Split logging functionality out of EAL Bruce Richardson
2023-07-31 15:39 ` [PATCH v7 1/3] eal/windows: move fnmatch function to header file Bruce Richardson
2023-08-09 11:18 ` David Marchand
2023-08-09 12:35 ` Bruce Richardson
2023-07-31 15:39 ` [PATCH v7 2/3] log: separate logging functions out of EAL Bruce Richardson
2023-07-31 16:22 ` David Marchand
2023-07-31 16:29 ` Bruce Richardson
2023-08-09 10:00 ` Bruce Richardson
2023-08-09 11:58 ` David Marchand
2023-08-09 12:24 ` David Marchand
2023-08-09 12:32 ` Bruce Richardson
2023-07-31 15:39 ` [PATCH v7 3/3] telemetry: use standard logging Bruce Richardson
2023-08-09 13:35 ` [PATCH v8 0/3] Split logging functionality out of EAL Bruce Richardson
2023-08-09 13:35 ` [PATCH v8 1/3] eal/windows: move fnmatch function to header file Bruce Richardson
2023-08-09 13:35 ` [PATCH v8 2/3] log: separate logging functions out of EAL Bruce Richardson
2023-08-09 13:35 ` [PATCH v8 3/3] telemetry: use standard logging Bruce Richardson
2023-08-11 12:46 ` [PATCH v8 0/3] Split logging functionality out of EAL David Marchand
2023-08-11 12:59 ` Bruce Richardson
2023-09-01 11:25 ` Thomas Monjalon [this message]
2023-09-01 12:26 ` Morten Brørup
2023-10-23 7:37 ` David Marchand
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=8822393.VV5PYv0bhD@thomas \
--to=thomas@monjalon.net \
--cc=anatoly.burakov@intel.com \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=dmitry.kozliuk@gmail.com \
--cc=harry.van.haaren@intel.com \
--cc=jerinj@marvell.com \
--cc=mb@smartsharesystems.com \
--cc=roretzla@linux.microsoft.com \
/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).