I checked the DPDK code which creates the extra mountpoint.
It only creates the extra mountpoints if
1. a given size e.g 1G is configured in dpdk.conf
2. no mountpoint for this size exists

In general a system always has /dev/hugepages at the "default" hugepagesz.
The default size can be changed as kernel parm, so this might be either one or 
another size.

Since DPDK wants to provide a simple way to get users going with it the 
hugepage setup is somewhat automated and working for non complex cases as 
outlined by the comment in the config file.
So if one is e.g. setting NR_1G_PAGES and 1G is not the current default size it 
will create a mountpoint. There the format is /dev/hugepages-${sizeinkb} then.

Qemu-kvm at the same time creates /run/hugepages/kvm if KVM_HUGEPAGES is
set.

To some extend that means if somebody adds more hugepage mountpoints to the 
system either via DPDK or otherwise this is a config change that needs other 
config changes to work well.
IMHO in this case one should set the hugetlbfs_mount in /etc/libvirt/qemu.conf 
- 
especially since this path is already allowed for apparmor.

Since we have a statistical reason to cause this I'll add it to the
libvirt profile, but in general that is more a configuration issue than
a bug.

In addition to my questions in comment #6 I'd ask to get a copy of
/etc/dpdk/dpdk.conf in your case if possible.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1680956

Title:
  Fail to launch an OpenStack Instance with hugepages on top of OVS+DPDK

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1680956/+subscriptions

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to