With the default sized hashtables, creation and deletion of instances in their own namespaces becomes prohibitively expensive. Without this change namespace creation and deletion can begin to take minutes instead of milliseconds when higher numbers of namespaces already exist on the machine (higher numbers = greater than 4000 namespaces).
As of commit 742ceaba530995da02ef5e5ac32f1478d60efd35 to the ubuntu-trusty kernel tree
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-trusty.git;a=commitdiff;h=742ceaba530995da02ef5e5ac32f1478d60efd35
Please see https://bugs.launchpad.net/linux/+bug/1328088 as well as it's use case directly applies to this tunable.
mhash_entries and mphash_entries are now a settable option for the kernel. These options adjust a hashtable that grows at n^2 the number of namespaces on the the machine. So if you have 4000 network namespaces on the neutron gateway 4000^2=16000000 entries will exist in the hashtable. Recently this value increased to 262144 entries by default *(4mb page size/sizeof(struct list_head)). That is enough to store 512 network namespaces without collisions in the hashtable.
So it is the recommendation of this engineer that deployments with large numbers of network namespaces add "mhash_entries=16000000 mphash_entries=16000000" to their kernel command line of at least the neutron gateway.
This would be enough to fit 4000 namespaces without collission.
My suggestion is that this should be sold as an expected number of namespaces config option with a default value of 4000 for neutron nodes. The charm should then square the value and edit /etc/default/grub GRUB_CMDLINE_LINUX appropriately and update-grub.
It is also important to note that with "mhash_
In order to remedy this massive amount of space the way ip creates a new namespace via CLONE_NEWNS would have to be completely reworked from userspace all the way down to kernel.