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.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.
We could also contribute to hwloc to have a similar simple output.
