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 B06314221F; Fri, 1 Sep 2023 13:25:33 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 3F3E740299; Fri, 1 Sep 2023 13:25:33 +0200 (CEST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mails.dpdk.org (Postfix) with ESMTP id 74B9C40285 for ; Fri, 1 Sep 2023 13:25:32 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D544B5C01BA; Fri, 1 Sep 2023 07:25:31 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Fri, 01 Sep 2023 07:25:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type: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= 1693567531; x=1693653931; bh=Oqy9+b4kfDRO7+NB+wopOi0BYEDkdMivKwJ 39dHWXQs=; b=BAbJY6Ozxrd5RC5yeSoxZmsREJV8YwaYUXDJB4DOO5Mk5B/VpYw 81tY9Ym1QUTvu2nB7MWIWa0zyXYb9eiddze/hbyGT5Y0ehPvdGDhcR/N+chbH8O4 Cmoi6USiXzdrLctCoORvqdzKNmJdAvfs98Uj+cCdsFb42yMC7h1VLINCyJC4wRnq 5M6PdLUyxaa8c68RVMPCncU5da6Q7CxQQLzefRhQ/JBs7F2IewOVoaMLadPeJ9PD LEOrvKWih2z2/SgJt90shDPLrigoor68TGSmZ2IDxLPSrBY8S8gWeKU6a3iAUKrh oyoaQh/j1mZ0dTVQV3OJ28B+CgLKSawG/Ww== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type: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= 1693567531; x=1693653931; bh=Oqy9+b4kfDRO7+NB+wopOi0BYEDkdMivKwJ 39dHWXQs=; b=jD6kdRLk2hkANoHqkRMFRoYRmZIrVLUYej/A7T8QFX5NhlXEdks xFyYy3/r4djZLqJ9EfpEsgGidJCAsWEijHAFdT6uvJKR5gIsAt5oy8ar7PVL7l2e +hRQSNFFTVOFGe035UEFIUcyIIbALvVrUyYC5E9iuGBLJISZYklOxRGWf3FD3Kn7 1WPeE1ejah7W+khffqk2AkdcNI4iDjf9zl0bgXE7KZ93hcm1YOECsPveo1aDWJY7 9XCKtE8zjJERF7q3vD3YZ9Ye0v0Yh5rnMTse9X9HE3M3y0sijsORLzkDAIaS1kBn XPbJXJmABocjLeOWz/Y3XQU1SPKN+psWoYQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudegvddgfeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeegtddtleejjeegffekkeektdejvedtheevtdekiedvueeuvdei uddvleevjeeujeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 1 Sep 2023 07:25:30 -0400 (EDT) From: Thomas Monjalon To: David Marchand , Bruce Richardson Cc: dev@dpdk.org, Morten =?ISO-8859-1?Q?Br=F8rup?= , anatoly.burakov@intel.com, dmitry.kozliuk@gmail.com, Tyler Retzlaff , 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 Message-ID: <8822393.VV5PYv0bhD@thomas> In-Reply-To: References: <20220829151901.376754-1-bruce.richardson@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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 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=E2=80=AFPM Bruce Richardson > > 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 tak= ing > > > the logging functionality out of EAL and putting it into its own libr= ary > > > 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 wo= uld > > > 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. > >=20 > > Series applied, thanks Bruce for this first step. > >=20 > > 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. >=20 > 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 -=20 > 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 c= an > 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?