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 715A0432D6; Wed, 8 Nov 2023 12:38:37 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 501E740A73; Wed, 8 Nov 2023 12:38:37 +0100 (CET) Received: from mail-yb1-f182.google.com (mail-yb1-f182.google.com [209.85.219.182]) by mails.dpdk.org (Postfix) with ESMTP id DC254402A1 for ; Tue, 7 Nov 2023 18:33:46 +0100 (CET) Received: by mail-yb1-f182.google.com with SMTP id 3f1490d57ef6-d9b315828aaso1218079276.0 for ; Tue, 07 Nov 2023 09:33:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699378426; x=1699983226; darn=dpdk.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=6g7UGZr69m/zJSoLv75aWkE/yVL/qLpjMAGWE/BX+no=; b=ljXSlpTcrjLB6WAcQ0hqDp4q4oaazPbj3YLQpdZfGIYYEoo4KCOlZG8w25rdHU30Uv BZ87gePS4Gzx7Ht5T2uIcha8EHaS4o7N+R5c1OAKDlrQp+j/IYc2NRWiXgf37HhpRXKE 5bTRkj+aVWk2iHu5UcEmn6+bJ1cutrTlgvl78oNfVhUFbo+0OjwrUTfFMuned5Wnb6kY NZgkoaIJdk1gmmUP83lP8dpSW/Z2NozF+Nc+k6ZkPDL1gK4kOp0gCsjc+9hn4m3Y9fu9 TEd1YqW7yENnxDNaukxP19Q8Tmw1Gc5bj3u8dW4cGR4NjgktBW44x7hd8tkPD5zx331P ElIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699378426; x=1699983226; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6g7UGZr69m/zJSoLv75aWkE/yVL/qLpjMAGWE/BX+no=; b=SSZNfXQMI70uUR57gD7wRqcqbhjHFAnIJznZtIzVdEaSsR4mOG8EMiSB+6TBgdmphz vlftITHLEfZlank+yaGrHVZKAydaRVwrDNXIOG/bDrK0X7QcyneDfgBpNhbCyAto+UZr NtgIsqq3dGq4z7KLfCqZMQ4cvdrZ0o6I2oO4ydmQmyIedGxwDuydp0f+UJq0uYkSY2pC 8WRFUGmr88Nrs1vmu+9jqosqz+VbvrVUDkIBlccEsnt42pfG8KeXzPuXryORjJpZQpH+ n7sq+XYfX3b7ncDJll87UhGhCIsS2DZyMq9XOifEm2Tus/RJl08qLCPp/i6emJJa1265 IMHg== X-Gm-Message-State: AOJu0YyNLIVm9sU9sKvwQ4ZaK1ybBsB/wPM9B3tp3EbVMBw6+XdlQVL8 EgjPEkEVZD7ab4SOJyYzZHjdeFGnHGpdZi8h8Dg= X-Google-Smtp-Source: AGHT+IGOOeyvkCZV9imttO54fk72nGA+/K3FCupEdcab5z9vgAqjSi83W5tKPzAE4r0Os7NvvZF1IHIyuYOg1EUm20E= X-Received: by 2002:a25:4289:0:b0:da6:e8d7:4030 with SMTP id p131-20020a254289000000b00da6e8d74030mr7646309yba.5.1699378425908; Tue, 07 Nov 2023 09:33:45 -0800 (PST) MIME-Version: 1.0 References: <1698949164-20287-1-git-send-email-rahulgupt@linux.microsoft.com> <20231102113759.341064ba@fedora> In-Reply-To: <20231102113759.341064ba@fedora> From: rahul gupta Date: Tue, 7 Nov 2023 23:03:34 +0530 Message-ID: Subject: Re: [RFC] eal: RFC to refactor rte_eal_init into sub-functions To: Stephen Hemminger Cc: Rahul Gupta , dev@dpdk.org, thomas@monjalon.net, sovaradh@linux.microsoft.com, okaya@kernel.org, sujithsankar@microsoft.com, sowmini.varadhan@microsoft.com, Rahul Gupta Content-Type: multipart/alternative; boundary="0000000000006a54310609935f99" X-Mailman-Approved-At: Wed, 08 Nov 2023 12:38:36 +0100 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 --0000000000006a54310609935f99 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Stephen, Thanks for your review. If I make it __rte_internal then, testpmd or our application can't use it. So instead I am planning to make it __rte_experimental. Regards, Rahul. On Fri, 3 Nov 2023 at 00:08, Stephen Hemminger wrote: > On Thu, 2 Nov 2023 11:19:24 -0700 > Rahul Gupta wrote: > > > From: Rahul Gupta > > To: dev@dpdk.org, thomas@monjalon.net > > Cc: sovaradh@linux.microsoft.com, okaya@kernel.org, > sujithsankar@microsoft.com, sowmini.varadhan@microsoft.com, > rahulrgupta27@gmail.com, Rahul Gupta , Rahul > Gupta > > Subject: [RFC] eal: RFC to refactor rte_eal_init into sub-functions > > Date: Thu, 2 Nov 2023 11:19:24 -0700 > > X-Mailer: git-send-email 1.8.3.1 > > > > From: Rahul Gupta > > > > 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. > > > > 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. > > > > 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()= . > > > > Existing applications require no changes unless they wish to leverage > > the optimization. > > > > 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. > > > > Signed-off-by: Rahul Gupta > > These probably marked internal rather than part of API/ABI. > --0000000000006a54310609935f99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Stephen,

Thanks for= your review.
If I make it __rte_internal then, testpmd or our ap= plication can't use it.
So instead I am planning to make it _= _rte_experimental.

Regards,
Rahul.
=

= On Fri, 3 Nov 2023 at 00:08, Stephen Hemminger <stephen@networkplumber.org> wrote:
On Thu,=C2=A0 2 Nov 2023 11= :19:24 -0700
Rahul Gupta <rahulgupt@linux.microsoft.com> wrote:

> From: Rahul Gupta <rahulgupt@linux.microsoft.com>
> To: dev@dpdk.org= ,=C2=A0 thomas@mon= jalon.net
> Cc: = sovaradh@linux.microsoft.com, okaya@kernel.org, sujithsankar@microsoft.com,=C2=A0 sowmini.varadhan@mic= rosoft.com, rahulrgupta27@gmail.com,=C2=A0 Rahul Gupta <rahulgupt@microsoft.com>,=C2= =A0 Rahul Gupta <rahulgupt@linux.microsoft.com>
> Subject: [RFC] eal: RFC to refactor rte_eal_init into sub-functions > Date: Thu,=C2=A0 2 Nov 2023 11:19:24 -0700
> X-Mailer: git-send-email 1.8.3.1
>
> From: Rahul Gupta <rahulgupt@microsoft.com>
>
> 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
>=C2=A0 =C2=A0 (200-250 ms in our use-case), this FLR is triggered durin= g device
>=C2=A0 =C2=A0 probe in rte_eal_init().
> b) rte_pktmbuf_pool_create() can consume upto 300-350 ms for
> applications that require huge memory.
>
> 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<= br> > can use and which can save 200-230ms.
>
> 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
>=C2=A0 =C2=A0 mempool creation. So this code needs to be executed befor= e any
>=C2=A0 =C2=A0 pthreads. Its named as rte_eal_init_setup()
> b) 2nd part of code is independent code ie- it can execute in parallel=
>=C2=A0 =C2=A0 to mempool creation in a pthread. Its named as rte_probe_= and_ioctl().
>
> Existing applications require no changes unless they wish to leverage<= br> > the optimization.
>
> 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=C2=A0 any other independent function.=
>
> Signed-off-by: Rahul Gupta <rahulgupt@linux.microsoft.com>

These probably marked internal rather than part of API/ABI.
--0000000000006a54310609935f99--