usertools: suggest use of hwloc for new cpu

Message ID 20230812005720.997-1-vipin.varghese@amd.com (mailing list archive)
State Rejected, archived
Delegated to: Thomas Monjalon
Headers
Series usertools: suggest use of hwloc for new cpu |

Checks

Context Check Description
ci/checkpatch success coding style OK
ci/loongarch-compilation success Compilation OK
ci/loongarch-unit-testing success Unit Testing PASS
ci/Intel-compilation success Compilation OK
ci/intel-Testing success Testing PASS
ci/intel-Functional success Functional PASS
ci/github-robot: build success github build: passed
ci/iol-compile-amd64-testing success Testing PASS
ci/iol-unit-amd64-testing success Testing PASS
ci/iol-unit-arm64-testing success Testing PASS
ci/iol-compile-arm64-testing success Testing PASS
ci/iol-sample-apps-testing success Testing PASS
ci/iol-broadcom-Performance success Performance Testing PASS
ci/iol-broadcom-Functional success Functional Testing PASS
ci/iol-intel-Functional success Functional Testing PASS
ci/iol-intel-Performance success Performance Testing PASS

Commit Message

Vipin Varghese Aug. 12, 2023, 12:57 a.m. UTC
  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 <vipin.varghese@amd.com>
---
---
 usertools/cpu_layout.py | 10 ++++++++++
 1 file changed, 10 insertions(+)
  

Comments

Stephen Hemminger Aug. 12, 2023, 3 p.m. UTC | #1
On Sat, 12 Aug 2023 06:27:20 +0530
Vipin Varghese <vipin.varghese@amd.com> 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 <vipin.varghese@amd.com>

NAK, no scripting hwloc, it is ugly and creates
a dependency that is not listed in DPDK packaging.

It would be better to just add a footnote now something like
cpu_layout script is deprecated use hwloc instead.
And include full deprecation notice in DPDK documentation.

Maybe there is a standard python way to mark whole script as deprecated.
  
Vipin Varghese Aug. 13, 2023, 2:12 a.m. UTC | #2
[AMD Official Use Only - General]

> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Saturday, August 12, 2023 8:30 PM
> To: Varghese, Vipin <Vipin.Varghese@amd.com>
> Cc: thomas@monjalon.net; dev@dpdk.org; Yigit, Ferruh
> <Ferruh.Yigit@amd.com>
> Subject: Re: [PATCH] usertools: suggest use of hwloc for new cpu
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Sat, 12 Aug 2023 06:27:20 +0530
> Vipin Varghese <vipin.varghese@amd.com> 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 <vipin.varghese@amd.com>
>
> 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.

>
> It would be better to just add a footnote now something like cpu_layout script
> is deprecated use hwloc instead.

Please try and let me know, This is exactly what it is does as pre-footer.

> And include full deprecation notice in DPDK documentation.
>
> Maybe there is a standard python way to mark whole script as deprecated.
With respect to depreciation please check the patchwork for `usertools: enahcne logic to display NUMA` all these are already discussed.

We even requested to remove the script if it is not be used.
  
Stephen Hemminger Aug. 13, 2023, 3:52 p.m. UTC | #3
On Sun, 13 Aug 2023 02:12:03 +0000
"Varghese, Vipin" <Vipin.Varghese@amd.com> wrote:

> >
> > On Sat, 12 Aug 2023 06:27:20 +0530
> > Vipin Varghese <vipin.varghese@amd.com> 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 <vipin.varghese@amd.com>  
> >
> > 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.
diff --git a/usertools/cpu_layout.py b/usertools/cpu_layout.py
index 891b9238fa19..37a4f9ff24b4 100755
--- a/usertools/cpu_layout.py
+++ b/usertools/cpu_layout.py
@@ -62,3 +62,8 @@
         else:
             output += " " * (max_core_map_len + 1)
     print(output)
+
+print("")
+print("This tool is unable to cope with complex NUMA layouts")
+print("and will be removed in a future release.")
+print("Suggest using lstopo or similar tools instead.")
  
Vipin Varghese Aug. 13, 2023, 4:35 p.m. UTC | #4
[AMD Official Use Only - General]

> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Sunday, August 13, 2023 9:22 PM
> To: Varghese, Vipin <Vipin.Varghese@amd.com>
> Cc: thomas@monjalon.net; dev@dpdk.org; Yigit, Ferruh
> <Ferruh.Yigit@amd.com>
> Subject: Re: [PATCH] usertools: suggest use of hwloc for new cpu
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On Sun, 13 Aug 2023 02:12:03 +0000
> "Varghese, Vipin" <Vipin.Varghese@amd.com> wrote:
>
> > >
> > > On Sat, 12 Aug 2023 06:27:20 +0530
> > > Vipin Varghese <vipin.varghese@amd.com> 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 <vipin.varghese@amd.com>
> > >
> > > 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.

Thanks Stephen, to that I agree `lstopo can change the flags and user might need in various format.`

>
> 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.
> diff --git a/usertools/cpu_layout.py b/usertools/cpu_layout.py index
> 891b9238fa19..37a4f9ff24b4 100755
> --- a/usertools/cpu_layout.py
> +++ b/usertools/cpu_layout.py
> @@ -62,3 +62,8 @@
>          else:
>              output += " " * (max_core_map_len + 1)
>      print(output)
> +
> +print("")
> +print("This tool is unable to cope with complex NUMA layouts")
> +print("and will be removed in a future release.") print("Suggest using
> +lstopo or similar tools instead.")

I am comfortable with the same as it serves the needs. I am happy to `ack` the same too.

> --
> 2.39.2
  
Bruce Richardson Aug. 14, 2023, 8:52 a.m. UTC | #5
On Sun, Aug 13, 2023 at 08:52:01AM -0700, Stephen Hemminger wrote:
> On Sun, 13 Aug 2023 02:12:03 +0000
> "Varghese, Vipin" <Vipin.Varghese@amd.com> wrote:
> 
> > >
> > > On Sat, 12 Aug 2023 06:27:20 +0530
> > > Vipin Varghese <vipin.varghese@amd.com> 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 <vipin.varghese@amd.com>  
> > >
> > > 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.

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.

/Bruce
  
Morten Brørup Aug. 14, 2023, 9:13 a.m. UTC | #6
> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
> Sent: Monday, 14 August 2023 10.52
> 
> On Sun, Aug 13, 2023 at 08:52:01AM -0700, Stephen Hemminger wrote:
> > On Sun, 13 Aug 2023 02:12:03 +0000
> > "Varghese, Vipin" <Vipin.Varghese@amd.com> wrote:
> >
> > > >
> > > > On Sat, 12 Aug 2023 06:27:20 +0530
> > > > Vipin Varghese <vipin.varghese@amd.com> 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 <vipin.varghese@amd.com>
> > > >
> > > > 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.
> 
> 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.
> 
> /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.
  
Konstantin Ananyev Aug. 14, 2023, 9:25 a.m. UTC | #7
> On Sun, Aug 13, 2023 at 08:52:01AM -0700, Stephen Hemminger wrote:
> > On Sun, 13 Aug 2023 02:12:03 +0000
> > "Varghese, Vipin" <Vipin.Varghese@amd.com> wrote:
> >
> > > >
> > > > On Sat, 12 Aug 2023 06:27:20 +0530
> > > > Vipin Varghese <vipin.varghese@amd.com> 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 <vipin.varghese@amd.com>
> > > >
> > > > 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.
> 
> 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.

+1
I do use it on regular basis.
It would be a pity if it will be gone.
Konstantin
  
Ferruh Yigit Sept. 4, 2023, 10:11 a.m. UTC | #8
On 8/14/2023 10:25 AM, Konstantin Ananyev wrote:
> 
>> On Sun, Aug 13, 2023 at 08:52:01AM -0700, Stephen Hemminger wrote:
>>> On Sun, 13 Aug 2023 02:12:03 +0000
>>> "Varghese, Vipin" <Vipin.Varghese@amd.com> wrote:
>>>
>>>>>
>>>>> On Sat, 12 Aug 2023 06:27:20 +0530
>>>>> Vipin Varghese <vipin.varghese@amd.com> 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 <vipin.varghese@amd.com>
>>>>>
>>>>> 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.
>>
>> 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.
> 
> +1
> I do use it on regular basis.
> It would be a pity if it will be gone.
>

I also use it time to time and find it useful.

But it is not accurate/correct for some AMD platforms (for various NPS
(Nodes per Socket) values).
So either it needs to be updated/improved or replaced.

Vipin sent a patch [1] to update it but it is question how much of this
logic belongs to DPDK, or should we rely on external tools dedicated for
this purpose.


Both are OK, if we can give a decision we can proceed on that direction.


[1]
https://patchwork.dpdk.org/project/dpdk/patch/20220326073207.489694-1-vipin.varghese@amd.com/
  
Bruce Richardson Sept. 4, 2023, 10:20 a.m. UTC | #9
On Mon, Sep 04, 2023 at 11:11:20AM +0100, Ferruh Yigit wrote:
> On 8/14/2023 10:25 AM, Konstantin Ananyev wrote:
> > 
> >> On Sun, Aug 13, 2023 at 08:52:01AM -0700, Stephen Hemminger wrote:
> >>> On Sun, 13 Aug 2023 02:12:03 +0000
> >>> "Varghese, Vipin" <Vipin.Varghese@amd.com> wrote:
> >>>
> >>>>>
> >>>>> On Sat, 12 Aug 2023 06:27:20 +0530
> >>>>> Vipin Varghese <vipin.varghese@amd.com> 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 <vipin.varghese@amd.com>
> >>>>>
> >>>>> 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.
> >>
> >> 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.
> > 
> > +1
> > I do use it on regular basis.
> > It would be a pity if it will be gone.
> >
> 
> I also use it time to time and find it useful.
> 
> But it is not accurate/correct for some AMD platforms (for various NPS
> (Nodes per Socket) values).
> So either it needs to be updated/improved or replaced.
> 
> Vipin sent a patch [1] to update it but it is question how much of this
> logic belongs to DPDK, or should we rely on external tools dedicated for
> this purpose.
> 

I'd like to suggest that we take a slightly ambiguous position on this
script. Specifically:

I think we should "recommend" but not "rely on" external tools for this.
Specifically, I think that recommending use of hwloc is the best thing to
do as it's better maintained and packaged for windows. However, for quick
use in many situations, cpu_layout does the job as well or better in terms
of simplicity of use and output.

/Bruce
  
Thomas Monjalon Sept. 4, 2023, 1:22 p.m. UTC | #10
04/09/2023 12:20, Bruce Richardson:
> On Mon, Sep 04, 2023 at 11:11:20AM +0100, Ferruh Yigit wrote:
> > On 8/14/2023 10:25 AM, Konstantin Ananyev wrote:
> > > 
> > >> On Sun, Aug 13, 2023 at 08:52:01AM -0700, Stephen Hemminger wrote:
> > >>> On Sun, 13 Aug 2023 02:12:03 +0000
> > >>> "Varghese, Vipin" <Vipin.Varghese@amd.com> wrote:
> > >>>
> > >>>>>
> > >>>>> On Sat, 12 Aug 2023 06:27:20 +0530
> > >>>>> Vipin Varghese <vipin.varghese@amd.com> 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 <vipin.varghese@amd.com>
> > >>>>>
> > >>>>> 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.
> > >>
> > >> 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.
> > > 
> > > +1
> > > I do use it on regular basis.
> > > It would be a pity if it will be gone.
> > >
> > 
> > I also use it time to time and find it useful.
> > 
> > But it is not accurate/correct for some AMD platforms (for various NPS
> > (Nodes per Socket) values).
> > So either it needs to be updated/improved or replaced.
> > 
> > Vipin sent a patch [1] to update it but it is question how much of this
> > logic belongs to DPDK, or should we rely on external tools dedicated for
> > this purpose.
> > 
> 
> I'd like to suggest that we take a slightly ambiguous position on this
> script. Specifically:
> 
> I think we should "recommend" but not "rely on" external tools for this.
> Specifically, I think that recommending use of hwloc is the best thing to
> do as it's better maintained and packaged for windows. However, for quick
> use in many situations, cpu_layout does the job as well or better in terms
> of simplicity of use and output.

We could also contribute to hwloc to have a similar simple output.
  

Patch

diff --git a/usertools/cpu_layout.py b/usertools/cpu_layout.py
index 891b9238fa..c8ac613878 100755
--- a/usertools/cpu_layout.py
+++ b/usertools/cpu_layout.py
@@ -29,6 +29,16 @@ 
         core_map[key] = []
     core_map[key].append(cpu)
 
+
+print("")
+print(format("=" * (55 + len(base_path))))
+print(" for newer CPU, that supports sub Socket Numa & L3 Numa clustering, please use")
+print(format("=" * (55 + len(base_path))))
+print("  - lstopo-no-graphics  --no-io -.ascii (CPU Mapping)")
+print("  - lstopo-no-graphics  -.ascii --whole-io --no-caches (IO device Mapping)")
+print(format("=" * (55 + len(base_path))))
+print("")
+
 print(format("=" * (47 + len(base_path))))
 print("Core and Socket Information (as reported by '{}')".format(base_path))
 print("{}\n".format("=" * (47 + len(base_path))))