Re: [dpdk-dev] [PATCH 1/8] doc: update Linux GSG system requirements section

[Thomas Monjalon <thomas@monjalon.net>]

28/11/2019 15:11, Bruce Richardson:
> On Thu, Nov 28, 2019 at 12:51:27PM +0100, Thomas Monjalon wrote:
> > 22/11/2019 17:03, Bruce Richardson:
> > [...]
> > > -*   GNU ``make``.
> > > +*   General development tools including ``make``, and a supported C compiler such as ``gcc`` or ``clang``.
> > 
> > Why referring to make and not meson?
> 
> Because even with meson build we still use make for building kernel
> modules, and this first bullet item is all about getting the basic build
> packages which come from build-essential etc. Make is part of that build
> tools group on distros, meson and ninja are not.

OK

> > > -*   gcc: versions 4.9 or later is recommended for all platforms.
> > > -    On some distributions, some specific compiler flags and linker flags are enabled by
> > > -    default and affect performance (``-fstack-protector``, for example). Please refer to the documentation
> > > -    of your distribution and to ``gcc -dumpspecs``.
> > 
> > I think we need to keep some compiler requirement somewhere.
> > What do you suggest?
> 
> I'm happy to keep this compiler requirements in here. Is 4.9 still
> regularly tested with DPDK to ensure it works? Also, if we put in a GCC
> requirement, do we not also need to put in a clang one? For recent distros
> is this really something most users need to worry about?

It allows us to know which compiler we must support.
And for distributions, it can help.
I think we should have clang version too.

> > > -    .. note::
> > > -
> > > -       x86_x32 ABI is currently supported with distribution packages only on Ubuntu
> > > -       higher than 13.10 or recent Debian distribution. The only supported  compiler is gcc 4.9+.
> > 
> > No note at all about x32?
> > Do we know how it is supported?
> > 
> 
> I'm not sure myself, and I'm also not certain if it is still used. However,
> even if it is used/supported, I'm not sure references belong in a getting
> started guide, which should only cover the basics really.

OK to drop note about x32.

> > > +*   Python, recommended version 3.5+.
> > > +    * Python v3.5+ is needed to build DPDK using meson and ninja
> > 
> > We cannot use meson at all with older Python?
> > 
> 
> Definitly not with python2, and I believe python 3.5 is the minimum
> supported version.

OK

> > > -*   Python, version 2.7+ or 3.2+, to use various helper scripts included in the DPDK package.
> > > +    * Python 2.7+ or 3.2+, to use various helper scripts included in the DPDK package.
> > 
> > I didn't know about 3.2 for scripts. Any special reason?
> > 
> 
> No idea. It is what was in the doc, so I just left it. Happy to take
> updates to this. When python 2 EOLs next year, we should probably drop all
> support and references to it.

OK

> > > +*   Meson (v0.47.1+) and ninja
> > >  
> > > +    * Recommended to use the latest versions from Python's "pip" repository:
> > > +      ``pip3 install meson ninja``
> > 
> > Why recommending pip? Is 0.47.1 enough?
> 
> It is enough, this was done again in the interests of simplification -
> rather than worry about what versions are in what distro and having the
> user check, it simplifies things if everyone just uses pip, which is why I
> recommend it.

I think we should let users take the responsibility of using their distro
package or pip.
Recommending pip is a little pushy.

> > > -    .. note::
> > > -
> > > -        On systems with NUMA support, `libnuma-dev` (aka `numactl-devel`)
> > > -        is a recommended dependency when `--legacy-mem` switch is used,
> > > -        and a *required* dependency if default memory mode is used.
> > > -        While DPDK will compile and run without `libnuma`
> > > -        even on NUMA-enabled systems,
> > > -        both usability and performance will be degraded.
> > 
> > I think libnuma is worth to be mentioned here as it is an EAL dependency.
> 
> It is mentioned. This just takes out the note about mandatory vs optional
> for different memory systems. After this patch the output still includes in
> the mandatory dependencies section:
> 
> 	Library for handling NUMA (Non Uniform Memory Access).
> 	* numactl-devel in Red Hat/Fedora;
> 	* libnuma-dev in Debian/Ubuntu;
> 
> So again we simplify to just saying to get libnuma rather that having the
> user worry about different memory systems.

OK I missed it.

> > > +**Additional Libraries**
> > > +
> > > +A number of DPDK components, such as libraries and poll-mode drivers (PMDs) have additional dependencies.
> > > +For DPDK builds using meson, the presence or absence of these dependencies will be
> > > +automatically detected enabling or disabling the relevant components appropriately.
> > > +
> > > +For builds using make, these components are disabled in the default configuration and
> > > +need to be enabled manually my changing the relevant setting to "y" in the build configuration file
> > 
> > typo: s/my/by/
> > 
> > > +i.e. the ``.config`` file in the build folder.
> > > +
> > > +In each case, the relevant library development package (``-devel`` or ``-dev``) is needed to build the DPDK components.
> > > +
> > > +For libraries the additional dependencies include:
> > > +
> > > +*   libarchive: for some unit tests using tar to get their resources.
> > > +
> > > +*   jansson: to compile and use the telemetry library.
> > > +
> > > +*   libelf: to compile and use the bpf library.
> > 
> > I think these optional dependencies could go away, thanks to the text
> > you added above and below.
> 
> I'd actually rather keep them here. While we could refer to the programmers
> guide, there are a lot of libraries and only 3 optional dependencies, so
> I'd rather explicitly list them here.
> 
> For drivers, the dependency list would be huge, so I'm just going to refer
> to the PMD guide for that.
> 
> > > +For poll-mode drivers, the additional dependencies for each driver can be
> > > +found in that driver's documentation in the relevant DPDK guide document,
> > > +e.g. Network Interface Controller Drivers Guide
> > 
> > Please use a link here.
> 
> Ok.
> 
> > You could also link the prog guide if talking about libraries.
> > 
> 
> I can add one, but I still think it's worth listing the 3 additional deps.
> :-)

OK, no strong opinion.