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 15BB543060; Mon, 14 Aug 2023 11:25:40 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9B16940A7F; Mon, 14 Aug 2023 11:25:39 +0200 (CEST) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by mails.dpdk.org (Postfix) with ESMTP id 2CBCC4021F for ; Mon, 14 Aug 2023 11:25:38 +0200 (CEST) Received: from frapeml100006.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4RPTRn1CVmz6J7kF; Mon, 14 Aug 2023 17:21:41 +0800 (CST) Received: from frapeml500007.china.huawei.com (7.182.85.172) by frapeml100006.china.huawei.com (7.182.85.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Mon, 14 Aug 2023 11:25:36 +0200 Received: from frapeml500007.china.huawei.com ([7.182.85.172]) by frapeml500007.china.huawei.com ([7.182.85.172]) with mapi id 15.01.2507.031; Mon, 14 Aug 2023 11:25:36 +0200 From: Konstantin Ananyev To: Bruce Richardson , Stephen Hemminger CC: "Varghese, Vipin" , "thomas@monjalon.net" , "dev@dpdk.org" , "Yigit, Ferruh" Subject: RE: [PATCH] usertools: suggest use of hwloc for new cpu Thread-Topic: [PATCH] usertools: suggest use of hwloc for new cpu Thread-Index: AQHZzLgi3HnksBsAwk6RWiJd078gYK/moHuAgAC7p4CAAOUYgIABHReAgAAqG5A= Date: Mon, 14 Aug 2023 09:25:36 +0000 Message-ID: References: <20230812005720.997-1-vipin.varghese@amd.com> <20230812080025.7626a94d@hermes.local> <20230813085201.719e7a73@hermes.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.206.138.42] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected 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 > 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 base= d 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 i= s 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_note= s/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 poss= ible > > + 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 looki= ng > to recommend alternatives, I actually find the script in it's current for= m > 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. +1 I do use it on regular basis. It would be a pity if it will be gone. Konstantin=20