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.vargh...@amd.com> wrote: > >>> > >>>>> > >>>>> On Sat, 12 Aug 2023 06:27:20 +0530 > >>>>> Vipin Varghese <vipin.vargh...@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.vargh...@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
