* [PATCH net-next 1/2] Support outside netns for tunnels.
@ 2016-01-04 18:45 Saurabh Mohan
2016-01-04 18:45 ` [PATCH net-next 2/2] Support outside netns for gre & vti tunnels Saurabh Mohan
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Saurabh Mohan @ 2016-01-04 18:45 UTC (permalink / raw)
To: netdev, stephen, davem, pshelar, tgraf; +Cc: Saurabh Mohan
This patch enchances a tunnel interface, like gre, to have the tunnel
encap/decap be in the context of a network namespace that is different from
the namespace of the tunnel interface.
>From userspace this feature may be configured using the new 'onetns' keyword:
ip netns exec custa ip link add dev tun1 type gre local 10.0.0.1 \
remote 10.0.0.2 onetns outside
In the above example the tunnel would be in the 'custa' namespace and the
tunnel endpoints would be in the 'outside' namespace.
Also, proposing the use of netns name 'global' to specify the global namespace.
If this patch set is accepted then I will add support for other tunnels as
well.
Signed-off-by: Saurabh Mohan <saurabh@cplanenetworks.com>
---
include/uapi/linux/if_tunnel.h | 19 +++++++++++++++++++
net/ipv4/ip_tunnel.c | 24 +++++++++++++++++++++---
2 files changed, 40 insertions(+), 3 deletions(-)
diff --git a/include/uapi/linux/if_tunnel.h b/include/uapi/linux/if_tunnel.h
index af4de90..2e43753 100644
--- a/include/uapi/linux/if_tunnel.h
+++ b/include/uapi/linux/if_tunnel.h
@@ -3,6 +3,7 @@
#include <linux/types.h>
#include <asm/byteorder.h>
+#include <linux/limits.h>
#define SIOCGETTUNNEL (SIOCDEVPRIVATE + 0)
@@ -27,6 +28,14 @@
#define GRE_FLAGS __cpu_to_be16(0x00F8)
#define GRE_VERSION __cpu_to_be16(0x0007)
+struct o_netns_parm {
+ __u8 o_netns_flag;
+ __u32 o_netns_fd;
+ char netns[NAME_MAX];
+};
+#define TUNNEL_ONETNS_FLAG_GLOBAL (1<<0)
+#define TUNNEL_ONETNS_FLAG_NETNS (1<<1)
+
struct ip_tunnel_parm {
char name[IFNAMSIZ];
int link;
@@ -35,6 +44,7 @@ struct ip_tunnel_parm {
__be32 i_key;
__be32 o_key;
struct iphdr iph;
+ struct o_netns_parm o_net;
};
enum {
@@ -57,6 +67,9 @@ enum {
IFLA_IPTUN_ENCAP_FLAGS,
IFLA_IPTUN_ENCAP_SPORT,
IFLA_IPTUN_ENCAP_DPORT,
+ IFLA_IPTUN_ONETNS_FLAGS,
+ IFLA_IPTUN_ONETNS_FD,
+ IFLA_IPTUN_ONETNS_NAME,
__IFLA_IPTUN_MAX,
};
#define IFLA_IPTUN_MAX (__IFLA_IPTUN_MAX - 1)
@@ -113,6 +126,9 @@ enum {
IFLA_GRE_ENCAP_SPORT,
IFLA_GRE_ENCAP_DPORT,
IFLA_GRE_COLLECT_METADATA,
+ IFLA_GRE_ONETNS_FLAGS,
+ IFLA_GRE_ONETNS_FD,
+ IFLA_GRE_ONETNS_NAME,
__IFLA_GRE_MAX,
};
@@ -128,6 +144,9 @@ enum {
IFLA_VTI_OKEY,
IFLA_VTI_LOCAL,
IFLA_VTI_REMOTE,
+ IFLA_VTI_ONETNS_FLAGS,
+ IFLA_VTI_ONETNS_FD,
+ IFLA_VTI_ONETNS_NAME,
__IFLA_VTI_MAX,
};
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index c7bd72e..f8dd717 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -259,6 +259,16 @@ static struct hlist_head *ip_bucket(struct ip_tunnel_net *itn,
return &itn->tunnels[h];
}
+static struct net *ip_tunnel_get_onet(struct net *inet,
+ struct ip_tunnel_parm *parms)
+{
+ if (parms->o_net.o_netns_flag == 0)
+ return inet;
+ if (parms->o_net.o_netns_flag & TUNNEL_ONETNS_FLAG_GLOBAL)
+ return &init_net;
+ return get_net_ns_by_fd(parms->o_net.o_netns_fd);
+}
+
static void ip_tunnel_add(struct ip_tunnel_net *itn, struct ip_tunnel *t)
{
struct hlist_head *head = ip_bucket(itn, &t->parms);
@@ -330,7 +340,7 @@ static struct net_device *__ip_tunnel_create(struct net *net,
tunnel = netdev_priv(dev);
tunnel->parms = *parms;
- tunnel->net = net;
+ tunnel->net = ip_tunnel_get_onet(net, &tunnel->parms);
err = register_netdevice(dev);
if (err)
@@ -818,6 +828,14 @@ static void ip_tunnel_update(struct ip_tunnel_net *itn,
t->parms.iph.daddr = p->iph.daddr;
t->parms.i_key = p->i_key;
t->parms.o_key = p->o_key;
+ if (strcmp(p->o_net.netns, t->parms.o_net.netns)) {
+ /* change the itn */
+ struct net *o_net = ip_tunnel_get_onet(dev_net(dev), p);
+
+ itn = net_generic(o_net, t->ip_tnl_net_id);
+ t->parms.o_net = p->o_net;
+ t->net = o_net;
+ }
if (dev->type != ARPHRD_ETHER) {
memcpy(dev->dev_addr, &p->iph.saddr, 4);
memcpy(dev->broadcast, &p->iph.daddr, 4);
@@ -1071,7 +1089,7 @@ int ip_tunnel_newlink(struct net_device *dev, struct nlattr *tb[],
struct ip_tunnel_parm *p)
{
struct ip_tunnel *nt;
- struct net *net = dev_net(dev);
+ struct net *net = ip_tunnel_get_onet(dev_net(dev), p);
struct ip_tunnel_net *itn;
int mtu;
int err;
@@ -1169,7 +1187,7 @@ int ip_tunnel_init(struct net_device *dev)
}
tunnel->dev = dev;
- tunnel->net = dev_net(dev);
+ tunnel->net = ip_tunnel_get_onet(dev_net(dev), &tunnel->parms);
strcpy(tunnel->parms.name, dev->name);
iph->version = 4;
iph->ihl = 5;
--
1.9.1
^ permalink raw reply related [flat|nested] 6+ messages in thread* [PATCH net-next 2/2] Support outside netns for gre & vti tunnels
2016-01-04 18:45 [PATCH net-next 1/2] Support outside netns for tunnels Saurabh Mohan
@ 2016-01-04 18:45 ` Saurabh Mohan
2016-01-04 19:47 ` [PATCH net-next 1/2] Support outside netns for tunnels Tom Herbert
2016-01-05 16:47 ` Nicolas Dichtel
2 siblings, 0 replies; 6+ messages in thread
From: Saurabh Mohan @ 2016-01-04 18:45 UTC (permalink / raw)
To: netdev, stephen, davem, pshelar, tgraf; +Cc: Saurabh Mohan
This patch enchances a tunnel interface, like gre, to have the tunnel
encap/decap be in the context of a network namespace that is different from
the namespace of the tunnel interface.
>From userspace this feature may be configured using the new 'onetns' keyword:
ip netns exec custa ip link add dev tun1 type gre local 10.0.0.1 \
remote 10.0.0.2 onetns outside
In the above example the tunnel would be in the 'custa' namespace and the
tunnel endpoints would be in the 'outside' namespace.
Also, proposing the use of netns name 'global' to specify the global namespace.
If this patch set is accepted then I will add support for other tunnels as
well.
This patches gre and vti
Signed-off-by: Saurabh Mohan <saurabh@cplanenetworks.com>
---
net/ipv4/ip_gre.c | 23 +++++++++++++++++++++++
net/ipv4/ip_vti.c | 21 +++++++++++++++++++++
2 files changed, 44 insertions(+)
diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c
index 7c51c4e..8376795 100644
--- a/net/ipv4/ip_gre.c
+++ b/net/ipv4/ip_gre.c
@@ -995,6 +995,16 @@ static void ipgre_netlink_parms(struct net_device *dev,
t->collect_md = true;
}
+ if (data[IFLA_GRE_ONETNS_FLAGS])
+ parms->o_net.o_netns_flag = nla_get_u8(
+ data[IFLA_GRE_ONETNS_FLAGS]);
+ if (data[IFLA_GRE_ONETNS_FD])
+ parms->o_net.o_netns_fd = nla_get_u32(
+ data[IFLA_GRE_ONETNS_FD]);
+ if (data[IFLA_GRE_ONETNS_NAME])
+ nla_strlcpy(parms->o_net.netns,
+ data[IFLA_GRE_ONETNS_NAME],
+ sizeof(parms->o_net.netns));
}
/* This function returns true when ENCAP attributes are present in the nl msg */
@@ -1128,6 +1138,12 @@ static size_t ipgre_get_size(const struct net_device *dev)
nla_total_size(2) +
/* IFLA_GRE_COLLECT_METADATA */
nla_total_size(0) +
+ /* IFLA_GRE_ONETNS_FLAGS */
+ nla_total_size(1) +
+ /* IFLA_GRE_ONETNS_FD */
+ nla_total_size(4) +
+ /* IFLA_GRE_ONETNS_NAME */
+ nla_total_size(NAME_MAX) +
0;
}
@@ -1164,6 +1180,13 @@ static int ipgre_fill_info(struct sk_buff *skb, const struct net_device *dev)
goto nla_put_failure;
}
+ if (p->o_net.o_netns_flag) {
+ if (nla_put_u8(skb, IFLA_GRE_ONETNS_FLAGS,
+ p->o_net.o_netns_flag) ||
+ nla_put_string(skb, IFLA_GRE_ONETNS_NAME, p->o_net.netns))
+ goto nla_put_failure;
+ }
+
return 0;
nla_put_failure:
diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c
index 5cf10b7..14b1015 100644
--- a/net/ipv4/ip_vti.c
+++ b/net/ipv4/ip_vti.c
@@ -466,6 +466,15 @@ static void vti_netlink_parms(struct nlattr *data[],
if (data[IFLA_VTI_REMOTE])
parms->iph.daddr = nla_get_in_addr(data[IFLA_VTI_REMOTE]);
+ if (data[IFLA_VTI_ONETNS_FLAGS])
+ parms->o_net.o_netns_flag = nla_get_u8(
+ data[IFLA_VTI_ONETNS_FLAGS]);
+ if (data[IFLA_VTI_ONETNS_FD])
+ parms->o_net.o_netns_fd = nla_get_u32(data[IFLA_VTI_ONETNS_FD]);
+ if (data[IFLA_VTI_ONETNS_NAME])
+ nla_strlcpy(parms->o_net.netns, data[IFLA_VTI_ONETNS_NAME],
+ sizeof(parms->o_net.netns));
+
}
static int vti_newlink(struct net *src_net, struct net_device *dev,
@@ -499,6 +508,12 @@ static size_t vti_get_size(const struct net_device *dev)
nla_total_size(4) +
/* IFLA_VTI_REMOTE */
nla_total_size(4) +
+ /* IFLA_VTI_ONETNS_FLAGS */
+ nla_total_size(1) +
+ /* IFLA_VTI_ONENTS_FD */
+ nla_total_size(4) +
+ /* IFLA_VTI_ONETNS_NAME */
+ nla_total_size(NAME_MAX) +
0;
}
@@ -512,6 +527,12 @@ static int vti_fill_info(struct sk_buff *skb, const struct net_device *dev)
nla_put_be32(skb, IFLA_VTI_OKEY, p->o_key);
nla_put_in_addr(skb, IFLA_VTI_LOCAL, p->iph.saddr);
nla_put_in_addr(skb, IFLA_VTI_REMOTE, p->iph.daddr);
+ if (p->o_net.o_netns_flag) {
+ if (nla_put_u8(skb, IFLA_VTI_ONETNS_FLAGS,
+ p->o_net.o_netns_flag) ||
+ nla_put_string(skb, IFLA_VTI_ONETNS_NAME, p->o_net.netns))
+ return -EMSGSIZE;
+ }
return 0;
}
--
1.9.1
^ permalink raw reply related [flat|nested] 6+ messages in thread* Re: [PATCH net-next 1/2] Support outside netns for tunnels.
2016-01-04 18:45 [PATCH net-next 1/2] Support outside netns for tunnels Saurabh Mohan
2016-01-04 18:45 ` [PATCH net-next 2/2] Support outside netns for gre & vti tunnels Saurabh Mohan
@ 2016-01-04 19:47 ` Tom Herbert
2016-01-04 19:54 ` Joe Perches
2016-01-05 16:47 ` Nicolas Dichtel
2 siblings, 1 reply; 6+ messages in thread
From: Tom Herbert @ 2016-01-04 19:47 UTC (permalink / raw)
To: Saurabh Mohan
Cc: Linux Kernel Network Developers, Stephen Hemminger,
David S. Miller, Pravin B Shelar, Thomas Graf
On Mon, Jan 4, 2016 at 10:45 AM, Saurabh Mohan
<saurabh@cplanenetworks.com> wrote:
>
> This patch enchances a tunnel interface, like gre, to have the tunnel
> encap/decap be in the context of a network namespace that is different from
> the namespace of the tunnel interface.
>
> From userspace this feature may be configured using the new 'onetns' keyword:
> ip netns exec custa ip link add dev tun1 type gre local 10.0.0.1 \
> remote 10.0.0.2 onetns outside
>
> In the above example the tunnel would be in the 'custa' namespace and the
> tunnel endpoints would be in the 'outside' namespace.
>
> Also, proposing the use of netns name 'global' to specify the global namespace.
>
> If this patch set is accepted then I will add support for other tunnels as
> well.
>
This might be interesting. Can you please ad a 0/n patch that
describes the motivation for this, in particular I would like to know
if this has a positive impact on ns performance if somehow we are
eliminating indirection.
Thanks,
Tom
> Signed-off-by: Saurabh Mohan <saurabh@cplanenetworks.com>
> ---
> include/uapi/linux/if_tunnel.h | 19 +++++++++++++++++++
> net/ipv4/ip_tunnel.c | 24 +++++++++++++++++++++---
> 2 files changed, 40 insertions(+), 3 deletions(-)
>
> diff --git a/include/uapi/linux/if_tunnel.h b/include/uapi/linux/if_tunnel.h
> index af4de90..2e43753 100644
> --- a/include/uapi/linux/if_tunnel.h
> +++ b/include/uapi/linux/if_tunnel.h
> @@ -3,6 +3,7 @@
>
> #include <linux/types.h>
> #include <asm/byteorder.h>
> +#include <linux/limits.h>
>
>
> #define SIOCGETTUNNEL (SIOCDEVPRIVATE + 0)
> @@ -27,6 +28,14 @@
> #define GRE_FLAGS __cpu_to_be16(0x00F8)
> #define GRE_VERSION __cpu_to_be16(0x0007)
>
> +struct o_netns_parm {
> + __u8 o_netns_flag;
> + __u32 o_netns_fd;
> + char netns[NAME_MAX];
> +};
> +#define TUNNEL_ONETNS_FLAG_GLOBAL (1<<0)
> +#define TUNNEL_ONETNS_FLAG_NETNS (1<<1)
> +
> struct ip_tunnel_parm {
> char name[IFNAMSIZ];
> int link;
> @@ -35,6 +44,7 @@ struct ip_tunnel_parm {
> __be32 i_key;
> __be32 o_key;
> struct iphdr iph;
> + struct o_netns_parm o_net;
> };
>
> enum {
> @@ -57,6 +67,9 @@ enum {
> IFLA_IPTUN_ENCAP_FLAGS,
> IFLA_IPTUN_ENCAP_SPORT,
> IFLA_IPTUN_ENCAP_DPORT,
> + IFLA_IPTUN_ONETNS_FLAGS,
> + IFLA_IPTUN_ONETNS_FD,
> + IFLA_IPTUN_ONETNS_NAME,
> __IFLA_IPTUN_MAX,
> };
> #define IFLA_IPTUN_MAX (__IFLA_IPTUN_MAX - 1)
> @@ -113,6 +126,9 @@ enum {
> IFLA_GRE_ENCAP_SPORT,
> IFLA_GRE_ENCAP_DPORT,
> IFLA_GRE_COLLECT_METADATA,
> + IFLA_GRE_ONETNS_FLAGS,
> + IFLA_GRE_ONETNS_FD,
> + IFLA_GRE_ONETNS_NAME,
> __IFLA_GRE_MAX,
> };
>
> @@ -128,6 +144,9 @@ enum {
> IFLA_VTI_OKEY,
> IFLA_VTI_LOCAL,
> IFLA_VTI_REMOTE,
> + IFLA_VTI_ONETNS_FLAGS,
> + IFLA_VTI_ONETNS_FD,
> + IFLA_VTI_ONETNS_NAME,
> __IFLA_VTI_MAX,
> };
>
> diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
> index c7bd72e..f8dd717 100644
> --- a/net/ipv4/ip_tunnel.c
> +++ b/net/ipv4/ip_tunnel.c
> @@ -259,6 +259,16 @@ static struct hlist_head *ip_bucket(struct ip_tunnel_net *itn,
> return &itn->tunnels[h];
> }
>
> +static struct net *ip_tunnel_get_onet(struct net *inet,
> + struct ip_tunnel_parm *parms)
> +{
> + if (parms->o_net.o_netns_flag == 0)
> + return inet;
> + if (parms->o_net.o_netns_flag & TUNNEL_ONETNS_FLAG_GLOBAL)
> + return &init_net;
> + return get_net_ns_by_fd(parms->o_net.o_netns_fd);
> +}
> +
> static void ip_tunnel_add(struct ip_tunnel_net *itn, struct ip_tunnel *t)
> {
> struct hlist_head *head = ip_bucket(itn, &t->parms);
> @@ -330,7 +340,7 @@ static struct net_device *__ip_tunnel_create(struct net *net,
>
> tunnel = netdev_priv(dev);
> tunnel->parms = *parms;
> - tunnel->net = net;
> + tunnel->net = ip_tunnel_get_onet(net, &tunnel->parms);
>
> err = register_netdevice(dev);
> if (err)
> @@ -818,6 +828,14 @@ static void ip_tunnel_update(struct ip_tunnel_net *itn,
> t->parms.iph.daddr = p->iph.daddr;
> t->parms.i_key = p->i_key;
> t->parms.o_key = p->o_key;
> + if (strcmp(p->o_net.netns, t->parms.o_net.netns)) {
> + /* change the itn */
> + struct net *o_net = ip_tunnel_get_onet(dev_net(dev), p);
> +
> + itn = net_generic(o_net, t->ip_tnl_net_id);
> + t->parms.o_net = p->o_net;
> + t->net = o_net;
> + }
> if (dev->type != ARPHRD_ETHER) {
> memcpy(dev->dev_addr, &p->iph.saddr, 4);
> memcpy(dev->broadcast, &p->iph.daddr, 4);
> @@ -1071,7 +1089,7 @@ int ip_tunnel_newlink(struct net_device *dev, struct nlattr *tb[],
> struct ip_tunnel_parm *p)
> {
> struct ip_tunnel *nt;
> - struct net *net = dev_net(dev);
> + struct net *net = ip_tunnel_get_onet(dev_net(dev), p);
> struct ip_tunnel_net *itn;
> int mtu;
> int err;
> @@ -1169,7 +1187,7 @@ int ip_tunnel_init(struct net_device *dev)
> }
>
> tunnel->dev = dev;
> - tunnel->net = dev_net(dev);
> + tunnel->net = ip_tunnel_get_onet(dev_net(dev), &tunnel->parms);
> strcpy(tunnel->parms.name, dev->name);
> iph->version = 4;
> iph->ihl = 5;
> --
> 1.9.1
>
> --
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH net-next 1/2] Support outside netns for tunnels.
2016-01-04 19:47 ` [PATCH net-next 1/2] Support outside netns for tunnels Tom Herbert
@ 2016-01-04 19:54 ` Joe Perches
0 siblings, 0 replies; 6+ messages in thread
From: Joe Perches @ 2016-01-04 19:54 UTC (permalink / raw)
To: Tom Herbert, Saurabh Mohan
Cc: Linux Kernel Network Developers, Stephen Hemminger,
David S. Miller, Pravin B Shelar, Thomas Graf
On Mon, 2016-01-04 at 11:47 -0800, Tom Herbert wrote:
> On Mon, Jan 4, 2016 at 10:45 AM, Saurabh Mohan
> <saurabh@cplanenetworks.com> wrote:
> >
> > This patch enchances a tunnel interface, like gre, to have the tunnel
> > encap/decap be in the context of a network namespace that is different from
> > the namespace of the tunnel interface.
> >
> > From userspace this feature may be configured using the new 'onetns' keyword:
> > ip netns exec custa ip link add dev tun1 type gre local 10.0.0.1 \
> > remote 10.0.0.2 onetns outside
> >
> > In the above example the tunnel would be in the 'custa' namespace and the
> > tunnel endpoints would be in the 'outside' namespace.
> >
> > Also, proposing the use of netns name 'global' to specify the global namespace.
> >
> > If this patch set is accepted then I will add support for other tunnels as
> > well.
> >
> This might be interesting. Can you please ad a 0/n patch that
> describes the motivation for this, in particular I would like to know
> if this has a positive impact on ns performance if somehow we are
> eliminating indirection.
[]
> > diff --git a/include/uapi/linux/if_tunnel.h b/include/uapi/linux/if_tunnel.h
[]
> > @@ -3,6 +3,7 @@
> >
> > #include
> > #include
> > +#include
> >
> >
> > #define SIOCGETTUNNEL (SIOCDEVPRIVATE + 0)
> > @@ -27,6 +28,14 @@
> > #define GRE_FLAGS __cpu_to_be16(0x00F8)
> > #define GRE_VERSION __cpu_to_be16(0x0007)
> >
> > +struct o_netns_parm {
> > + __u8 o_netns_flag;
> > + __u32 o_netns_fd;
> > + char netns[NAME_MAX];
> > +};
Trivia:
It could eliminate a few padding bytes if the
o_netns_fd and o_netns_flag fields were reversed.
and netns[NAME_MAX] is normally netns[NAME_MAX + 1]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH net-next 1/2] Support outside netns for tunnels.
2016-01-04 18:45 [PATCH net-next 1/2] Support outside netns for tunnels Saurabh Mohan
2016-01-04 18:45 ` [PATCH net-next 2/2] Support outside netns for gre & vti tunnels Saurabh Mohan
2016-01-04 19:47 ` [PATCH net-next 1/2] Support outside netns for tunnels Tom Herbert
@ 2016-01-05 16:47 ` Nicolas Dichtel
2016-01-07 18:59 ` Saurabh Mohan
2 siblings, 1 reply; 6+ messages in thread
From: Nicolas Dichtel @ 2016-01-05 16:47 UTC (permalink / raw)
To: Saurabh Mohan, netdev, stephen, davem, pshelar, tgraf
Le 04/01/2016 19:45, Saurabh Mohan a écrit :
>
> This patch enchances a tunnel interface, like gre, to have the tunnel
> encap/decap be in the context of a network namespace that is different from
> the namespace of the tunnel interface.
>
> From userspace this feature may be configured using the new 'onetns' keyword:
> ip netns exec custa ip link add dev tun1 type gre local 10.0.0.1 \
> remote 10.0.0.2 onetns outside
>
> In the above example the tunnel would be in the 'custa' namespace and the
> tunnel endpoints would be in the 'outside' namespace.
What is the difference with the following commands?
ip netns exec outside ip link add dev tun1 type gre local 10.0.0.1 \
remote 10.0.0.2
ip netns exec outside ip link set tun1 netns custa
or
ip exec custa ip netns set outside 1234
ip exec custa ip link add tun1 link-netnsid 1234 type gre local 10.0.0.1 \
remote 10.0.0.2
Regards,
Nicolas
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH net-next 1/2] Support outside netns for tunnels.
2016-01-05 16:47 ` Nicolas Dichtel
@ 2016-01-07 18:59 ` Saurabh Mohan
0 siblings, 0 replies; 6+ messages in thread
From: Saurabh Mohan @ 2016-01-07 18:59 UTC (permalink / raw)
To: nicolas.dichtel, netdev, stephen, davem, pshelar, tgraf
On 01/05/2016 08:47 AM, Nicolas Dichtel wrote:
> Le 04/01/2016 19:45, Saurabh Mohan a écrit :
>>
>> This patch enchances a tunnel interface, like gre, to have the tunnel
>> encap/decap be in the context of a network namespace that is different from
>> the namespace of the tunnel interface.
>>
>> From userspace this feature may be configured using the new 'onetns' keyword:
>> ip netns exec custa ip link add dev tun1 type gre local 10.0.0.1 \
>> remote 10.0.0.2 onetns outside
>>
>> In the above example the tunnel would be in the 'custa' namespace and the
>> tunnel endpoints would be in the 'outside' namespace.
> What is the difference with the following commands?
>
> ip netns exec outside ip link add dev tun1 type gre local 10.0.0.1 \
> remote 10.0.0.2
> ip netns exec outside ip link set tun1 netns custa
>
> or
>
> ip exec custa ip netns set outside 1234
> ip exec custa ip link add tun1 link-netnsid 1234 type gre local 10.0.0.1 \
> remote 10.0.0.2
>
>
these methods would be functionally equivalent to what this patch does.
no point in adding a third way to do the same.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-01-07 20:31 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-01-04 18:45 [PATCH net-next 1/2] Support outside netns for tunnels Saurabh Mohan
2016-01-04 18:45 ` [PATCH net-next 2/2] Support outside netns for gre & vti tunnels Saurabh Mohan
2016-01-04 19:47 ` [PATCH net-next 1/2] Support outside netns for tunnels Tom Herbert
2016-01-04 19:54 ` Joe Perches
2016-01-05 16:47 ` Nicolas Dichtel
2016-01-07 18:59 ` Saurabh Mohan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).