[PATCH] usertools: suggest use of hwloc for new cpu

[PATCH] usertools: suggest use of hwloc for new cpu

[Vipin Varghese]

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(+)

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))))
-- 
2.34.1

Re: [PATCH] usertools: suggest use of hwloc for new cpu

[Stephen Hemminger]

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.

RE: [PATCH] usertools: suggest use of hwloc for new cpu

[Varghese, Vipin]

[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.

Re: [PATCH] usertools: suggest use of hwloc for new cpu

[Stephen Hemminger]

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.")
-- 
2.39.2

RE: [PATCH] usertools: suggest use of hwloc for new cpu

[Varghese, Vipin]

[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

Re: [PATCH] usertools: suggest use of hwloc for new cpu

[Bruce Richardson]

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

RE: [PATCH] usertools: suggest use of hwloc for new cpu

[Morten Brørup]

> 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.

RE: [PATCH] usertools: suggest use of hwloc for new cpu

[Konstantin Ananyev]

> 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 

Re: [PATCH] usertools: suggest use of hwloc for new cpu

[Ferruh Yigit]

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/

Re: [PATCH] usertools: suggest use of hwloc for new cpu

[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.

/Bruce

Re: [PATCH] usertools: suggest use of hwloc for new cpu

[Thomas Monjalon]

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] usertools: suggest use of hwloc for new cpu

[Vipin Varghese]

Most modern processor now supports numa partitioning using
sub NUMA 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(+)

diff --git a/usertools/cpu_layout.py b/usertools/cpu_layout.py
index 891b9238fa..48c1f06d95 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 more porcessors, which support 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))))
-- 
2.34.1