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 9EF5643060; Mon, 14 Aug 2023 11:13:13 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8C533410F1; Mon, 14 Aug 2023 11:13:13 +0200 (CEST) Received: from dkmailrelay1.smartsharesystems.com (smartserver.smartsharesystems.com [77.243.40.215]) by mails.dpdk.org (Postfix) with ESMTP id 9439A4021F for ; Mon, 14 Aug 2023 11:13:12 +0200 (CEST) Received: from smartserver.smartsharesystems.com (smartserver.smartsharesys.local [192.168.4.10]) by dkmailrelay1.smartsharesystems.com (Postfix) with ESMTP id 7B2BB205ED; Mon, 14 Aug 2023 11:13:12 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH] usertools: suggest use of hwloc for new cpu Date: Mon, 14 Aug 2023 11:13:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D87AF7@smartserver.smartshare.dk> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] usertools: suggest use of hwloc for new cpu Thread-Index: AdnOjK1KPFfkd+3ZTp6oNDxU3umgwgAAc/QQ References: <20230812005720.997-1-vipin.varghese@amd.com> <20230812080025.7626a94d@hermes.local> <20230813085201.719e7a73@hermes.local> From: =?iso-8859-1?Q?Morten_Br=F8rup?= To: "Bruce Richardson" , "Stephen Hemminger" Cc: "Varghese, Vipin" , , , "Yigit, Ferruh" 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 > From: Bruce Richardson [mailto:bruce.richardson@intel.com] > Sent: Monday, 14 August 2023 10.52 >=20 > On Sun, Aug 13, 2023 at 08:52:01AM -0700, Stephen Hemminger wrote: > > On Sun, 13 Aug 2023 02:12:03 +0000 > > "Varghese, Vipin" wrote: > > > > > > > > > > On Sat, 12 Aug 2023 06:27:20 +0530 > > > > Vipin Varghese wrote: > > > > > > > > > Most modern processor now supports numa by partitioning NUMA = based on > > > > > CPU-IO & Last Level Cache within the same socket. > > > > > As per the discussion in mailing list, suggesting the make use = of > > > > > hw-loc for such scenarios. > > > > > > > > > > Signed-off-by: Vipin Varghese > > > > > > > > NAK, no scripting hwloc, it is ugly and creates a dependency = that is not > listed > > > > in DPDK packaging. > > > > > > There is no calls to hwloc within in thescript. Hence not clear = what does > ` NAK, no scripting hwloc it is ugly and creates a dependency that is = not > listed in DPDK packaging.`. > > > > > > Requesting to cross check why NAK is shared for `print` as = suggestion. > Hence, I have disagree to this. > > > > Sorry, I misinterpreted what the print's were doing. > > Better off not to list exact flags, the lstopo may change and user = may want > different > > format anyway. > > > > How about something like this? > > > > > > doc/guides/rel_notes/deprecation.rst | 5 +++++ > > usertools/cpu_layout.py | 5 +++++ > > 2 files changed, 10 insertions(+) > > > > diff --git a/doc/guides/rel_notes/deprecation.rst > b/doc/guides/rel_notes/deprecation.rst > > index 317875c5054b..25a116900dfb 100644 > > --- a/doc/guides/rel_notes/deprecation.rst > > +++ b/doc/guides/rel_notes/deprecation.rst > > @@ -185,3 +185,8 @@ Deprecation Notices > > will be deprecated and subsequently removed in DPDK 24.11 = release. > > Before this, the new port library API (functions rte_swx_port_*) > > will gradually transition from experimental to stable status. > > + > > +* cpulayout: The CPU layout script is unable to deal with all the = possible > > + complexities of modern CPU topology. Other existing tools offer = more > > + features and do a better job with keeping up with innovations. > > + Therefore it will be deprecated and removed in a future release. >=20 > Does the script really do that bad a job? While I can understand us = looking > to recommend alternatives, I actually find the script in it's current = form > really handy - much more so than working out the exact flags for = lstopo > etc. Since it's not a large maintenance burden, I'd request we keep it > around - while still recommending lstopo to users. >=20 > /Bruce Also, if lstopo has other dependencies than libc, it might be cumbersome = for non-distro usage. Although, I guess it is only used for hardware = bring-up in those cases anyway. In short: I agree with Bruce on this.