David Ahern <lxhacker68@xxxxxxxxx> writes: > On 9/26/14, 1:34 PM, Eric W. Biederman wrote: >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
