[dpdk-dev] [PATCH 1/8] doc: update Linux GSG system requirements section
Thomas Monjalon
thomas at monjalon.net
Thu Nov 28 15:22:05 CET 2019
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.
More information about the dev
mailing list