Message ID | 20081028174659.GF8471@thomson.net |
---|---|
State | Deferred, archived |
Delegated to: | David Miller |
Headers | show |
Vivien Chappelier wrote:
> This allows the creation of more than one network namespace at boot time.
I'm wondering, what is the advantage over creating them manually?
They have to be configured by userspace to be useful anyway, don't
they?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, Yes; the linux-vrf patches had a new netlink message to create/remove the equivalent of a network namespace (ip vrf add 1). I've not ported this feature yet, so this patch is meant to provide another way of setting up networking stacks without the need for a new process for each stack. The ability to dynamically create/remove networking stacks from userspace would definitely be useful. There are also some very minor advantages in creating the namespaces statically at boot time, such as increasing the chances that the allocation works (though network namespaces are quite small), and improving boot time by avoiding a few calls to /sbin/ip on startup. Since we are running on embedded devices, that is something that matter to us, but it may not be enough to justify the need for this feature. Anyway, I do not think it hurts to have the ability to create static networking stacks at boot time. regards, Vivien. Patrick McHardy wrote: > Vivien Chappelier wrote: >> This allows the creation of more than one network namespace at boot >> time. > > I'm wondering, what is the advantage over creating them manually? > They have to be configured by userspace to be useful anyway, don't > they? > > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Vivien Chappelier wrote: > Yes; the linux-vrf patches had a new netlink message to create/remove > the equivalent of a network namespace (ip vrf add 1). I've not ported > this feature yet, so this patch is meant to provide another way of > setting up networking stacks without the need for a new process for each > stack. The ability to dynamically create/remove networking stacks from > userspace would definitely be useful. I see, I didn't realize the process that created a namespace needs to be kept running. So yes, creating standalone network namespaces seems to make sense. > There are also some very minor advantages in creating the namespaces > statically at boot time, such as increasing the chances that the > allocation works (though network namespaces are quite small), and > improving boot time by avoiding a few calls to /sbin/ip on startup. > Since we are running on embedded devices, that is something that matter > to us, but it may not be enough to justify the need for this feature. > Anyway, I do not think it hurts to have the ability to create static > networking stacks at boot time. I don't have an opinion on this. Thanks for the explanation. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Patrick McHardy <kaber@trash.net> writes: > Vivien Chappelier wrote: >> Yes; the linux-vrf patches had a new netlink message to create/remove the >> equivalent of a network namespace (ip vrf add 1). I've not ported this feature >> yet, so this patch is meant to provide another way of setting up networking >> stacks without the need for a new process for each stack. The ability to >> dynamically create/remove networking stacks from userspace would definitely be >> useful. > > I see, I didn't realize the process that created a namespace > needs to be kept running. So yes, creating standalone network > namespaces seems to make sense To be clear a reference needs to be kept to the network namespace. Either by being the network namespace that new sockets are created in task->nsproxy->netns or the network namespace of an open socket sock_net(sk). If neither of those two conditions hold the network namespace count drops to zero and it will be freed. Probably not ideal if you are just doing routing. Eric -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/net/Kconfig b/net/Kconfig index 8c3d97c..c896bdf 100644 --- a/net/Kconfig +++ b/net/Kconfig @@ -32,6 +32,13 @@ config NET_NS Allow user space to create what appear to be multiple instances of the network stack. +config NET_NS_NR + int "Initial number of network namespaces" + default 1 + depends on NET_NS + help + Number of network stacks to create at start-up. + source "net/packet/Kconfig" source "net/unix/Kconfig" source "net/xfrm/Kconfig" diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c index 596cb83..1cafa31 100644 --- a/net/core/net_namespace.c +++ b/net/core/net_namespace.c @@ -297,8 +297,25 @@ static int __init net_ns_init(void) rtnl_unlock(); mutex_unlock(&net_mutex); + +#if defined(CONFIG_NET_NS) && CONFIG_NET_NS_NR > 1 + /* Create additional initial namespaces */ + { + struct net *net; + int i; + + for (i = 1; i < CONFIG_NET_NS_NR; i++) { + net = copy_net_ns(CLONE_NEWNET, &init_net); + if (IS_ERR(net)) { + err = PTR_ERR(net); + break; + } + } + } +#endif + if (err) - panic("Could not setup the initial network namespace"); + panic("Could not setup the initial network namespace(s)"); return 0; }