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 8883D432D8; Wed, 8 Nov 2023 16:40:43 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 710D240693; Wed, 8 Nov 2023 16:40:43 +0100 (CET) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by mails.dpdk.org (Postfix) with ESMTP id 498F3402A7 for ; Wed, 8 Nov 2023 16:40:42 +0100 (CET) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id AEF383200977; Wed, 8 Nov 2023 10:40:40 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 08 Nov 2023 10:40:41 -0500 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=fm3; t= 1699458040; x=1699544440; bh=VzrYfTjNtI0oD8v/zzsYPUrLeK6wJ5q1NZq 1cvL38cc=; b=VmQhW24V/Ibt/rzbffLteDDJ3DnE3dX4igrbU2XwLBMIauIQRrm rCxAlzxzXtK5xZ+E3x3EaV7CmBvzM0iDcaZ2Iu3cxDgJrmI/rGqrqOMF2b2r4Jjz 7jY8SvuK4TTSrbPlc468I8G4gjJ8P7J84ZVGBT2grjyi7UObFyvj6dJ2RsRi9+N0 i2U6YLLgAyAM0++xi1lODhhzChx2+V9pMz3JF8cpG3Ouz25lFgsb+NlLjxh3dylK 7VzZrQEEQzA55cX1XTKaO0qpv91z0dAW+PiL42sNuFBiX3HX/UJgxB3QRvnIjjWD 0G5uGdhShxgstj64rmsgjMje+UgIiELQ9DQ== 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=fm3; t= 1699458040; x=1699544440; bh=VzrYfTjNtI0oD8v/zzsYPUrLeK6wJ5q1NZq 1cvL38cc=; b=nK18IURxTJjoVRO1U6DAwpjdDRe2/ZhU7x1iuDfmyXzskwVKaZI 52RLih89HgRgiLnaP2XWRvpnlxBJFgZa5Lc0vqiFMgE6SzgO1FLStmeBe/hU/0mN BE/zoLzjf74vfLTnIasr7x7UDWi7CrZFTqM0VG+GWtLVXbAA3dd7UnZljEjH5Ltn 7LLgx59QmRPDF8o83uJZbPhXOGBONV6gTFqRbSrDEVphsLTNZYrtxugLD5daROz6 bVBEv0cBjBSrcqVtIMVi0vmyt6UqjbU/IQGIGtNj47BDhwrB4un5Fra7JoA7CCND AoEXfMpmg9KEGlEXuMXpe3MAQl8EES5oPow== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudduledgjeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeegtddtleejjeegffekkeektdejvedtheevtdekiedvueeuvdei uddvleevjeeujeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 8 Nov 2023 10:40:38 -0500 (EST) From: Thomas Monjalon To: Rahul Gupta , Bruce Richardson Cc: dev@dpdk.org, sovaradh@linux.microsoft.com, okaya@kernel.org, sujithsankar@microsoft.com, sowmini.varadhan@microsoft.com, rahulrgupta27@gmail.com, Rahul Gupta Subject: Re: [RFC] eal: RFC to refactor rte_eal_init into sub-functions Date: Wed, 08 Nov 2023 16:40:37 +0100 Message-ID: <3091501.U3zVgo479M@thomas> In-Reply-To: References: <1698949164-20287-1-git-send-email-rahulgupt@linux.microsoft.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 08/11/2023 12:51, Bruce Richardson: > On Thu, Nov 02, 2023 at 11:19:24AM -0700, Rahul Gupta wrote: > > From: Rahul Gupta > >=20 > > Initialization often requires rte_eal_init + rte_pktmbuf_pool_create > > which can consume a total time of 500-600 ms: > > a) For many devices FLR may take a significant chunk of time > > (200-250 ms in our use-case), this FLR is triggered during device > > probe in rte_eal_init(). > > b) rte_pktmbuf_pool_create() can consume upto 300-350 ms for > > applications that require huge memory. > >=20 > > This cost is incurred on each restart (which happens in our use-case > > during binary updates for servicing). > > This patch provides an optimization using pthreads that appplications > > can use and which can save 200-230ms. > >=20 > > In this patch, rte_eal_init() is refactored into two parts- > > a) 1st part is dependent code ie- it=E2=80=99s a perquisite of the FLR = and > > mempool creation. So this code needs to be executed before any > > pthreads. Its named as rte_eal_init_setup() > > b) 2nd part of code is independent code ie- it can execute in parallel > > to mempool creation in a pthread. Its named as rte_probe_and_ioctl(). > >=20 > > Existing applications require no changes unless they wish to leverage > > the optimization. > >=20 > > If the application wants to use pthread functionality, it should call- > > a) rte_eal_init_setup() then create two or more pthreads- > > b) in one pthread call- rte_probe_and_ioctl(), > > c) second pthread call- rte_pktmbuf_pool_create() > > d) (optional) Other pthreads for any other independent function. > >=20 > > Signed-off-by: Rahul Gupta >=20 > Reading the description, this seems an interesting idea, and a good savin= g. >=20 > If I may, I wonder if I can suggest a slight alternative. Rather than > splitting EAL init into two functions like that, how about providing an > "rte_eal_init_async()" function, which does part 1, and then spawns a > thread for part 2, before returning. We can then provide an > rte_eal_init_done() [or eal_init_async_done()] function to allow apps to > resync and check for EAL being done. >=20 > The reason for suggesting this is that the naming and purpose of the APIs > may be a little clearer for the end user. Allowing the async init function > to create threads also allows possible future parallelism in the function > itself. For example, we could do probing of the devices themselves in > parallel. I like the idea of async init.