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

[Bruce Richardson <bruce.richardson@intel.com>]

On Thu, Nov 28, 2019 at 12:51:27PM +0100, Thomas Monjalon wrote:
> 22/11/2019 17:03, Bruce Richardson:
> > Update the system requirements section of the doc to cover builds with
> > meson and ninja. This involves updating the package dependencies to include
> > meson, ninja and python 3.5, and also updating the optional dependencies
> > section to explain that the components are enabled/disabled automatically
> > by meson.
> > 
> > As part of this update, the relevant sections were simplified to keep the
> > document shorter. For mandatory requirements, we can refer to the various
> > distro's development tools package groups rather than requiring gcc, core
> > tools etc. individually. The optional package list was very incomplete, and
> > if complete would duplicate information in the individual driver's guides.
> > Therefore we can simplify it by listing only the library optional
> > requirements and referring users to the driver docs to find details on
> > their dependencies.
> 
> I agree with the intent.
> 

And thanks for the review.

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

> 
> > -*   coreutils: ``cmp``, ``sed``, ``grep``, ``arch``, etc.
> > +    * For Red Hat/Fedora systems these can be installed using ``dnf groupinstall "Development Tools"``
> > +    * For Ubuntu/Debian systems these can be installed using ``apt install build-essential``
> 
> OK, this is very basic :)

That's the intent. No point in asking the user to get gcc and coreutils
etc. individually when packagers give us a shortcut :-)

> 
> > -*   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?

> 
> > -*   libc headers, often packaged as ``gcc-multilib`` (``glibc-devel.i686`` / ``libc6-dev-i386``;
> > -    ``glibc-devel.x86_64`` / ``libc6-dev`` for 64-bit compilation on Intel architecture;
> > -    ``glibc-devel.ppc64`` for 64 bit IBM Power architecture;)
> [...]
> > -*   Additional packages required for 32-bit compilation on 64-bit systems are:
> > -    * glibc.i686, libgcc.i686, libstdc++.i686 and glibc-devel.i686 for Intel i686/x86_64;
> > -    * glibc.ppc64, libgcc.ppc64, libstdc++.ppc64 and glibc-devel.ppc64 for IBM ppc_64;
> 
> OK to drop libc requirements.
> 
> > -    .. 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.

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

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

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

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

> 
> > +*   Linux kernel headers or sources required to build kernel modules.
> 
> This one is obvious, OK.
> 
> > -*   libpcap headers and libraries (libpcap-devel) to compile and use the libpcap-based poll-mode driver.
> > -    This driver is disabled by default and can be enabled by setting ``CONFIG_RTE_LIBRTE_PMD_PCAP=y`` in the build time config file.
> 
> OK to drop PMD-specific requirement.
> 
> > +**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.
:-)

/Bruce