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.
