Re: [RFC PATCH net-next v2 0/5] netns: allow to identify peer netns

David Ahern [off-list ref] writes:

On 9/26/14, 1:34 PM, Eric W. Biederman wrote:

quoted

When I wrote the "ip netns" support I never expected that all
applications would want to run in a specific network namespace.  All
that is needed is one socket per network namespace.

Sure that is another option. But for a process to create a socket or
thread in a second namespace it has to run as root -- CAP_SYS_ADMIN is
needed for setns (or perhaps there is another way to create the socket
or thread in the namespace).

To do anything other than simply listen on a netlink socket you also
have to be root.  So this is most cases that I am aware of this is a
don't care.  Especially for routing daemons.

If it becomes a common pain in writing network namespace aware
applications that the you have to be root just to open your listening
socket then that probably would be sufficient justification for the
socketat system call that I have I prototyped and then never did
anything with because at the time it was insufficiently interesting.

Second, it still does not address the scalability problem. For example
a single daemon providing service across 2k namespaces means it needs
2k listen sockets. From there a system could have 20, 30 or 50
services running. Certainly lighter than a process per namespace, but
not even close to ideal when talking about something like VRFs.

Ah.  You are talking about a system with 2k namespaces and 20-50
services providing services in all 2k namespaces. Something completely
different than the case of quagga you mentioned earlier.

I expect quagga would need one netlink control socket and one socket
listening to netlink events, and a tcp connection or two to remote bgp
servers in each network namespace.  In that case I don't see anything
except a small constant difference in ways it can be handled.

For your new example of a crazy number of servers running on a box each
of which is had one listening socket in each network namespace maybe
they will be idle most of the time in most network namespaces and the
overhead will be significant.  Shrug those applications don't appear to
exist so I can't say what would make a good design.

If someone writes them and describes what is going on we can see if the
current set of interfaces is ideal or problematics.  If there are
signifcantly better interfaces that can be provided in a maintainable
way I imagine the patches would be easily accepted.

But again this has nothing do with the peer netns work.  So if you have
something practical to contribute please start a new thread.

Eric