Re: [PATCH net-next 1/2] Support outside netns for tunnels.

On Mon, 2016-01-04 at 11:47 -0800, Tom Herbert wrote:

On Mon, Jan 4, 2016 at 10:45 AM, Saurabh Mohan
[off-list ref] wrote:

quoted

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.

[]

quoted

diff --git a/include/uapi/linux/if_tunnel.h b/include/uapi/linux/if_tunnel.h

[]

quoted

@@ -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]