netdev - Re: [iproute PATCH 0/2] Netns performance improvements

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 07 Jul 2016 11:34:36 -0500
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Rick Jones <rick.jones2@....com>
Cc:	Phil Sutter <phil@....cc>,
	Nicolas Dichtel <nicolas.dichtel@...nd.com>,
	Stephen Hemminger <shemming@...cade.com>,
	netdev@...r.kernel.org
Subject: Re: [iproute PATCH 0/2] Netns performance improvements

Rick Jones <rick.jones2@....com> writes:

> On 07/07/2016 08:48 AM, Phil Sutter wrote:
>> On Thu, Jul 07, 2016 at 02:59:48PM +0200, Nicolas Dichtel wrote:
>>> Le 07/07/2016 13:17, Phil Sutter a écrit :
>>> [snip]
>>>> The issue came up during OpenStack Neutron testing, see this ticket for
>>>> reference:
>>>>
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1310795
>>> Access to this ticket is not public :(
>>
>> *Sigh* OK, here are a few quotes:
>>
>> "OpenStack Neutron controller nodes, when undergoing testing, are
>> locking up specifically during creation and mounting of namespaces.
>> They appear to be blocking behind vfsmount_lock, and contention for the
>> namespace_sem"
>>
>> "During the scale testing, we have 300 routers, 600 dhcp namespaces
>> spread across four neutron network nodes. When then start as one set of
>> standard Openstack Rally benchmark test cycle against neutron. An
>> example scenario is creating 10x networks, list them, delete them and
>> repeat 10x times. The second set performs an L3 benchmark test between
>> two instances."
>>
>
> Those 300 routers will each have at least one namespace along with the
> dhcp namespaces.  Depending on the nature of the routers (Distributed
> versus Centralized Virtual Routers - DVR vs CVR) and whether the
> routers are supposed to be "HA" there can be more than one namespace
> for a given router.
>
> 300 routers is far from the upper limit/goal.  Back in HP Public
> Cloud, we were running as many as 700 routers per network node (*),
> and more than four network nodes. (back then it was just the one
> namespace per router and network). Mileage will of course vary based
> on the "oomph" of one's network node(s).

To clarify processes for these routers and dhcp servers are created
with "ip netns exec"?

If that is the case and you are using this feature as effectively a
lightweight container and not lots vrfs in a single network stack
then I suspect much larger gains can be had by creating a variant
of ip netns exec avoids the mount propagation.

> happy benchmarking,
>
> rick jones
>
> * Didn't want to go much higher than that because each router had a
> port on a common linux bridge and getting to > 1024 would be an
> unpleasant day.

* I would have thought all you have to do is bump of the size
  of the linux neighbour cache.  echo $BIGNUM > /proc/sys/net/ipv4/neigh/default/gc_thresh3 

Eric