1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
|
#
# The number of 2M hugepages to reserve on system boot
#
# Default is 0
# To e.g. let it reserve 128M via 64x 2M Hugepages set:
# NR_2M_PAGES=64
# For numa systems multiple numbers in one space separated line
# can be used. To e.g. reserve those 128M on the second node
# NR_2M_PAGES="0 64"
#
# The number of 1G hugepages to reserve on system boot
#
# Default is 0
# To e.g. let it reserve 2G via 2x 1G Hugepages set:
# NR_1G_PAGES=2
# same for numa node1
# NR_1G_PAGES="0 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
# same for numa node0
# NR_16M_PAGES="32 0"
#
# Dropping slab and pagecache can help to successfully allocate hugepages,
# especially later in the lifecycle of a system.
# This comes at the cost of loosing all slab and pagecache on (re)start
# of the dpdk service - therefore the default is off.
#
# Default is 0
# Set to 1 to enable it
#DROPCACHE_BEFORE_HP_ALLOC=0
#
# When using other hugepage allocation mechanisms (e.g. kernel commandline)
# this script might find pre-allocated pages. This can also happen when the
# script is run multiple times with configuration changing.
# In this case the script will free previously allocated pages by default
# but that freeing can be disabled.
#
# Default is 1
# Set to 0 to disable it
#FREE_PREVIOUS_ALLOCATIONS=1
# The DPDK library will use the first mounted hugetlbfs.
# The init scripts try to ensure there is at least one default hugetlbfs
# mountpoint on start.
# If you have multiple hugetlbfs mountpoints for a complex setup it should
# be controlled by the admin instead of this init 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
# not allocate the requested amount of hugepages.
# The more or the larger the hugepages to be allocated are, the more it is
# recommended to do the reservation as kernel commandline arguments.
# To do so edit /etc/default/grub: GRUB_CMDLINE_LINUX_DEFAULT
# and add [hugepagesz=xx] hugepages=yy ...
#
# Kernel commandline config:
# hugepagesz sets the size for the next hugepages reservation (default 2M)
# hugepages reserves the given number of hugepages of the size set before
#
# After modifying /etc/default/grub, the command "update-grub" has to be
# run in order to re-generate the grub config files. The new values will
# be used after next reboot.
#
# example:
# GRUB_CMDLINE_LINUX_DEFAULT="... hugepages=16 hugepagesz=1G hugepages=2"
#
# If the system supports it, this will reserve 16x 2M pages and 2x 1G pages.
#
|
