changelog: New Upstream release 17.05.2

[deb_dpdk.git] / debian / dpdk.conf

diff --git a/debian/dpdk.conf b/debian/dpdk.conf
index fb4572d..272565c 100644 (file)
--- a/debian/dpdk.conf
+++ b/debian/dpdk.conf
@@ -2,16 +2,22 @@
 # The number of 2M hugepages to reserve on system boot
 #
 # Default is 0
-# To e.g. let it reserve 64x 2M Hugepages set:
+# To e.g. let it reserve 128M via 64x 2M Hugepages set:
 # NR_2M_PAGES=64
 
 #
 # The number of 1G hugepages to reserve on system boot
 #
 # Default is 0
-# To e.g. let it reserve 2x 1G Hugepages set:
+# To e.g. let it reserve 2G via 2x 1G Hugepages set:
 # NR_1G_PAGES=2
 
+# The number of 16M hugepages to reserve, supported e.g. on ppc64el
+#
+# Default is 0
+# To e.g. let it reserve 512M via 32x 16M Hugepages set:
+# NR_16M_PAGES=32
+
 #
 # Dropping slab and pagecache can help to successfully allocate hugepages,
 # especially later in the lifecycle of a system.
@@ -30,6 +36,14 @@
 # script. In that case specific mountpoints can be provided as parameters to
 # the DPDK library.
 
+# Also please be aware that multiple huge page sizes and their mountpoints
+# can confuse other programs as well. For example libvirt/qemu might pick one
+# of the paths created for DPDKs larger pages or any such.
+# It is recommended in these cases to consider configuring the respective
+# applications as well to not "guess" when picking a hugepage path.
+# In the libvirt/qemu case that would for example be the setting
+# hugetlbfs_mount in /etc/libvirt/qemu.conf
+
 # Hardware may support other granularities of hugepages (like 4M). But the
 # larger the hugepages the earlier those should be allocated.
 # Note: the dpdk init scripts will report warnings, but not fail if they could