Virtual ethernet tunnel

Veth stands for Virtual ETHernet. It is a simple tunnel driver that works at the link layer and looks like a pair of ethernet devices interconnected with each other.

Mainly it allows to communicate between network namespaces but it can be used as is as well.

Eric recently sent a similar driver called etun. This implementation uses another interface - the RTM_NRELINK message introduced by Patric. The patch fits today netdev tree with Patrick's patches.

The newlink callback is organized that way to make it easy to create the peer device in the separate namespace when we have them in kernel.

drivers/net/veth.c new file +6 -0

+static int veth_xmit(struct sk_buff *skb, struct net_device *dev)
+{
+	struct net_device *rcv = NULL;
+	struct veth_priv *priv, *rcv_priv;
+	int length;
+

Veth stands for Virtual ETHernet. It is a simple tunnel driver that works at the link layer and looks like a pair of ethernet devices interconnected with each other.

Mainly it allows to communicate between network namespaces but it can be used as is as well.

Eric recently sent a similar driver called etun. This implementation uses another interface - the RTM_NRELINK message introduced by Patric. The patch fits today netdev tree with Patrick's patches.

The newlink callback is organized that way to make it easy to create the peer device in the separate namespace when we have them in kernel.

The patch for an ip utility is also provided.

Eric, since ethtool interface was from your patch, I add your Signed-off-by line.

Signed-off-by Eric W. Biederman <[email protected]>

Signed-off-by Pavel Emelianov <[email protected]>

---

drivers/net/Kconfig +6 -0

index 7d57f4a..7e144be 100644
@@ -119,6 +119,12 @@ config TUN
 
 	  If you don't know what to use this for, you don't need it.
 
+config VETH
+	tristate "Virtual ethernet device"
+	---help---
+	  The device is an ethernet tunnel. Devices are created in pairs. When
+	  one end receives the packet it appears on its pair and vice versa.
+
 config NET_SB1000
 	tristate "General Instruments Surfboard 1000"
 	depends on PNP

drivers/net/Makefile +1 -0

index a77affa..4764119 100644
@@ -185,6 +185,7 @@ obj-$(CONFIG_MACSONIC) += macsonic.o
 obj-$(CONFIG_MACMACE) += macmace.o
 obj-$(CONFIG_MAC89x0) += mac89x0.o
 obj-$(CONFIG_TUN) += tun.o
+obj-$(CONFIG_VETH) += veth.o
 obj-$(CONFIG_NET_NETX) += netx-eth.o
 obj-$(CONFIG_DL2K) += dl2k.o
 obj-$(CONFIG_R8169) += r8169.o

drivers/net/veth.c new file +28 -0

new file mode 100644
index 0000000..6746c91
@@ -0,0 +1,391 @@
+/*
+ *  drivers/net/veth.c
+ *
+ *  Copyright (C) 2007 OpenVZ http://openvz.org, SWsoft Inc
+ *
+ */
+
+#include <linux/list.h>
+#include <linux/netdevice.h>
+#include <linux/ethtool.h>
+#include <linux/etherdevice.h>
+
+#include <net/dst.h>
+#include <net/xfrm.h>
+#include <net/veth.h>
+
+#define DRV_NAME	"veth"
+#define DRV_VERSION	"1.0"
+
+struct veth_priv {
+	struct net_device *peer;
+	struct net_device *dev;
+	struct list_head list;
+	struct net_device_stats stats;
+	unsigned ip_summed;
+};
+
+static LIST_HEAD(veth_list);

drivers/net/veth.c new file +28 -0

+/*
+ * xmit
+ */
+
+static int veth_xmit(struct sk_buff *skb, struct net_device *dev)
+{
+	struct net_device *rcv = NULL;
+	struct veth_priv *priv, *rcv_priv;
+	int length;
+
+	skb_orphan(skb);
+
+	priv = netdev_priv(dev);
+	rcv = priv->peer;
+	rcv_priv = netdev_priv(rcv);
+
+	if (!(rcv->flags & IFF_UP))
+		goto outf;
+
+	skb->dev = rcv;
+	skb->pkt_type = PACKET_HOST;
+	skb->protocol = eth_type_trans(skb, rcv);
+	if (dev->features & NETIF_F_NO_CSUM)
+		skb->ip_summed = rcv_priv->ip_summed;
+
+	dst_release(skb->dst);
+	skb->dst = NULL;
+

drivers/net/veth.c new file +8 -0

+	netif_rx(skb);
+	return 0;
+
+outf:
+	kfree_skb(skb);
+	priv->stats.tx_dropped++;
+	return 0;
+}

Veth stands for Virtual ETHernet. It is a simple tunnel driver that works at the link layer and looks like a pair of ethernet devices interconnected with each other.

From: Pavel Emelianov <[email protected]>
Date: Wed, 06 Jun 2007 19:11:38 +0400

Quoted 4 lines

Veth stands for Virtual ETHernet. It is a simple tunnel driver that works at the link layer and looks like a pair of ethernet devices interconnected with each other.

I would suggest choosing a different name.

'veth' is also the name of the virtualized ethernet device found on IBM machines, driven by driver/net/ibmveth.[ch]

Perhaps, a name like "epipe" or "npipe", which reflects what does the device, is more appropriate ?

Quoted 16 lines · Pavel Emelianov

Veth stands for Virtual ETHernet. It is a simple tunnel driver that works at the link layer and looks like a pair of ethernet devices interconnected with each other.

Mainly it allows to communicate between network namespaces but it can be used as is as well.

Eric recently sent a similar driver called etun. This implementation uses another interface - the RTM_NRELINK message introduced by Patric. The patch fits today netdev tree with Patrick's patches.

The newlink callback is organized that way to make it easy to create the peer device in the separate namespace when we have them in kernel.

drivers/net/veth.c line 24

Quoted 5 lines

drivers/net/veth.c new file +5 -0

+struct veth_priv {
+	struct net_device *peer;
+	struct net_device *dev;
+	struct list_head list;
+	struct net_device_stats stats;

You can use dev->stats instead.

Quoted 10 lines

drivers/net/veth.c new file +10 -0

+static int veth_xmit(struct sk_buff *skb, struct net_device *dev)
+{
+	struct net_device *rcv = NULL;
+	struct veth_priv *priv, *rcv_priv;
+	int length;
+
+	skb_orphan(skb);
+
+	priv = netdev_priv(dev);
+	rcv = priv->peer;

drivers/net/veth.c line 151

Quoted 6 lines

drivers/net/veth.c new file +6 -0

+	rcv_priv = netdev_priv(rcv);
+
+	if (!(rcv->flags & IFF_UP))
+		goto outf;
+
+	skb->dev = rcv;

eth_type_trans already sets skb->dev.

Quoted 6 lines

drivers/net/veth.c new file +6 -0

+	skb->pkt_type = PACKET_HOST;
+	skb->protocol = eth_type_trans(skb, rcv);
+	if (dev->features & NETIF_F_NO_CSUM)
+		skb->ip_summed = rcv_priv->ip_summed;
+
+	dst_release(skb->dst);

drivers/net/veth.c line 161

Quoted 4 lines

drivers/net/veth.c new file +4 -0

+	skb->dst = NULL;
+
+	secpath_reset(skb);
+	nf_reset(skb);

Is skb->mark supposed to survive communication between different namespaces?

Quoted 4 lines

drivers/net/veth.c new file +4 -0

+static const struct nla_policy veth_policy[VETH_INFO_MAX] = {
+	[VETH_INFO_MAC]		= { .type = NLA_BINARY, .len = ETH_ALEN },
+	[VETH_INFO_PEER]	= { .type = NLA_STRING },
+	[VETH_INFO_PEER_MAC]	= { .type = NLA_BINARY, .len = ETH_ALEN },

Quoted 1 line

+};

The rtnl_link codes looks fine. I don't like the VETH_INFO_MAC attribute very much though, we already have a generic device attribute for MAC addresses. Of course that only allows you to supply one MAC address, so I'm wondering what you think of allocating only a single device per newlink operation and binding them in a seperate enslave operation?

include/net/veth.h line 11

Quoted 8 lines

include/net/veth.h new file +8 -0

+enum {
+	VETH_INFO_UNSPEC,
+	VETH_INFO_MAC,
+	VETH_INFO_PEER,
+	VETH_INFO_PEER_MAC,
+
+	VETH_INFO_MAX
+};

Please follow the

#define VETH_INFO_MAX (__VETH_INFO_MAX - 1)

convention here.

-
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

From: Pavel Emelianov <[email protected]>
Date: Wed, 06 Jun 2007 19:11:38 +0400

Quoted 3 lines

Veth stands for Virtual ETHernet. It is a simple tunnel driver that works at the link layer and looks like a pair of ethernet devices interconnected with each other.

I would suggest choosing a different name.

'veth' is also the name of the virtualized ethernet device found on IBM machines, driven by driver/net/ibmveth.[ch]

Quoted 9 lines · David Miller

From: Pavel Emelianov <[email protected]>
Date: Wed, 06 Jun 2007 19:11:38 +0400

Quoted 3 lines

Veth stands for Virtual ETHernet. It is a simple tunnel driver that works at the link layer and looks like a pair of ethernet devices interconnected with each other.

Quoted 4 lines

I would suggest choosing a different name.

'veth' is also the name of the virtualized ethernet device found on IBM machines, driven by driver/net/ibmveth.[ch]

AFAICS, ibmveth.c registers ethX devices, while this driver registers vethX by default, so there is no much conflict IMHO.

Quoted 19 lines · Patrick McHardy

Quoted 17 lines · Pavel Emelianov

Veth stands for Virtual ETHernet. It is a simple tunnel driver that works at the link layer and looks like a pair of ethernet devices interconnected with each other.

Mainly it allows to communicate between network namespaces but it can be used as is as well.

Eric recently sent a similar driver called etun. This implementation uses another interface - the RTM_NRELINK message introduced by Patric. The patch fits today netdev tree with Patrick's patches.

The newlink callback is organized that way to make it easy to create the peer device in the separate namespace when we have them in kernel.

Quoted 8 lines

drivers/net/veth.c line 24

Quoted 6 lines

drivers/net/veth.c new file +5 -0

+struct veth_priv {
+	struct net_device *peer;
+	struct net_device *dev;
+	struct list_head list;
+	struct net_device_stats stats;

You can use dev->stats instead.

OK. Actually I planned to use percpu stats to reduce cacheline trashing (Stephen has noticed it also). The reason I didn't do it here is that the patch would look more complicated, but I wanted to show and approve the netlink interface first.

Quoted 10 lines

Quoted 10 lines

drivers/net/veth.c new file +10 -0

+static int veth_xmit(struct sk_buff *skb, struct net_device *dev)
+{
+	struct net_device *rcv = NULL;
+	struct veth_priv *priv, *rcv_priv;
+	int length;
+
+	skb_orphan(skb);
+
+	priv = netdev_priv(dev);
+	rcv = priv->peer;

Quoted 9 lines

drivers/net/veth.c line 151

Quoted 7 lines

drivers/net/veth.c new file +6 -0

+	rcv_priv = netdev_priv(rcv);
+
+	if (!(rcv->flags & IFF_UP))
+		goto outf;
+
+	skb->dev = rcv;

eth_type_trans already sets skb->dev.

Ok. Thanks.

Quoted 5 lines

Quoted 5 lines

drivers/net/veth.c new file +5 -0

+	skb->pkt_type = PACKET_HOST;
+	skb->protocol = eth_type_trans(skb, rcv);
+	if (dev->features & NETIF_F_NO_CSUM)
+		skb->ip_summed = rcv_priv->ip_summed;
+

Quoted 9 lines

drivers/net/veth.c line 161

Quoted 6 lines

drivers/net/veth.c new file +5 -0

+	dst_release(skb->dst);
+	skb->dst = NULL;
+
+	secpath_reset(skb);
+	nf_reset(skb);

Is skb->mark supposed to survive communication between different namespaces?

I guess it must not. Thanks.

Quoted 12 lines

drivers/net/veth.c line 354

Quoted 6 lines

drivers/net/veth.c new file +5 -0

+static const struct nla_policy veth_policy[VETH_INFO_MAX] = {
+	[VETH_INFO_MAC]		= { .type = NLA_BINARY, .len = ETH_ALEN },
+	[VETH_INFO_PEER]	= { .type = NLA_STRING },
+	[VETH_INFO_PEER_MAC]	= { .type = NLA_BINARY, .len = ETH_ALEN },
+};

The rtnl_link codes looks fine. I don't like the VETH_INFO_MAC attribute very much though, we already have a generic device attribute for MAC addresses. Of course that only allows you to supply one MAC address, so I'm wondering what you think of allocating only a single device per newlink operation and binding them in a seperate enslave operation?

I did this at the very first version, but Alexey showed me that this
would be wrong. Look. When we create the second device it must be in
the other namespace as it is useless to have them in one namespace.
But if we have the device in the other namespace the RTNL_NEWLINK message from kernel would come into this namespace thus confusing ip utility in the init namespace. Creating the device in the init ns and
moving it into the new one is rather a complex task.

But with such approach the creation looks really logical. We send a packet to the kernel and have a single response about the new device appearance. At the same time we have a RTNL_NEWLINK message arrived at the destination namespace informing that a new device has appeared there as well.

Quoted 11 lines

include/net/veth.h line 11

Quoted 9 lines

include/net/veth.h new file +8 -0

+enum {
+	VETH_INFO_UNSPEC,
+	VETH_INFO_MAC,
+	VETH_INFO_PEER,
+	VETH_INFO_PEER_MAC,
+
+	VETH_INFO_MAX
+};

Please follow the

Quoted 4 lines

#define VETH_INFO_MAX (__VETH_INFO_MAX - 1)

convention here.

Could you please clarify this point. I saw the lines

enum {
	...
	RTNL_NEWLINK
#define RTNL_NEWLINK RTNL_NEWLINK
	...
}

and had my brains exploded imagining what this would mean :(

Quoted 6 lines

-
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

_______________________________________________
Containers mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/containers

From: Kirill Korotaev <[email protected]>
Date: Thu, 07 Jun 2007 12:14:29 +0400

Quoted 9 lines

Quoted 8 lines · David Miller

From: Pavel Emelianov <[email protected]>
Date: Wed, 06 Jun 2007 19:11:38 +0400

Quoted 3 lines

Veth stands for Virtual ETHernet. It is a simple tunnel driver that works at the link layer and looks like a pair of ethernet devices interconnected with each other.

Quoted 6 lines

Quoted 4 lines

I would suggest choosing a different name.

'veth' is also the name of the virtualized ethernet device found on IBM machines, driven by driver/net/ibmveth.[ch]

AFAICS, ibmveth.c registers ethX devices, while this driver registers vethX by default, so there is no much conflict IMHO.

If that's the case, veth is fine with me.

Quoted 8 lines

I did this at the very first version, but Alexey showed me that this would be wrong. Look. When we create the second device it must be in the other namespace as it is useless to have them in one namespace. But if we have the device in the other namespace the RTNL_NEWLINK message from kernel would come into this namespace thus confusing ip utility in the init namespace. Creating the device in the init ns and moving it into the new one is rather a complex task.

Pavel,

moving the netdevice to another namespace is not a complex task. Eric Biederman did it in its patchset ( cf. http://lxc.sf.net/network )

When the pair device is created, both extremeties are into the init namespace and you can choose to which namespace to move one extremity.

When the network namespace dies, the netdev is moved back to the init namespace.
That facilitate network device management.

Concerning netlink events, this is automatically generated when the network device is moved through namespaces.

IMHO, we should have the network device movement between namespaces in order to be able to move a physical network device too (eg. you have 4 NIC and you want to create 3 containers and assign 3 NIC to each of them)

Quoted 9 lines

Quoted 9 lines

I did this at the very first version, but Alexey showed me that this would be wrong. Look. When we create the second device it must be in the other namespace as it is useless to have them in one namespace. But if we have the device in the other namespace the RTNL_NEWLINK message from kernel would come into this namespace thus confusing ip utility in the init namespace. Creating the device in the init ns and moving it into the new one is rather a complex task.

Quoted 5 lines

Pavel,

moving the netdevice to another namespace is not a complex task. Eric Biederman did it in its patchset ( cf. http://lxc.sf.net/network )

By saying complex I didn't mean that this is difficult to implement, but that it consists (must consist) of many stages. I.e. composite. Making the device right in the namespace is liter.

Quoted 3 lines

When the pair device is created, both extremeties are into the init namespace and you can choose to which namespace to move one extremity.

I do not mind that.

Quoted 11 lines

When the network namespace dies, the netdev is moved back to the init namespace.
That facilitate network device management.

Concerning netlink events, this is automatically generated when the network device is moved through namespaces.

IMHO, we should have the network device movement between namespaces in order to be able to move a physical network device too (eg. you have 4 NIC and you want to create 3 containers and assign 3 NIC to each of them)

Agree. Moving the devices is a must-have functionality.

I do not mind making the pair in the init namespace and move the second one into the desired namespace. But if we *always* will have two ends in different namespaces what to complicate things for?

Thanks,
Pavel

Quoted 41 lines · Pavel Emelianov

Quoted 10 lines

Quoted 9 lines

I did this at the very first version, but Alexey showed me that this would be wrong. Look. When we create the second device it must be in the other namespace as it is useless to have them in one namespace. But if we have the device in the other namespace the RTNL_NEWLINK message from kernel would come into this namespace thus confusing ip utility in the init namespace. Creating the device in the init ns and moving it into the new one is rather a complex task.

Quoted 5 lines

Pavel,

moving the netdevice to another namespace is not a complex task. Eric Biederman did it in its patchset ( cf. http://lxc.sf.net/network )

By saying complex I didn't mean that this is difficult to implement, but that it consists (must consist) of many stages. I.e. composite. Making the device right in the namespace is liter.

Quoted 3 lines

When the pair device is created, both extremeties are into the init namespace and you can choose to which namespace to move one extremity.

I do not mind that.

Quoted 11 lines

When the network namespace dies, the netdev is moved back to the init namespace.
That facilitate network device management.

Concerning netlink events, this is automatically generated when the network device is moved through namespaces.

IMHO, we should have the network device movement between namespaces in order to be able to move a physical network device too (eg. you have 4 NIC and you want to create 3 containers and assign 3 NIC to each of them)

Quoted 6 lines

Agree. Moving the devices is a must-have functionality.

I do not mind making the pair in the init namespace and move the second one into the desired namespace. But if we *always* will have two ends in different namespaces what to complicate things for?

Just to provide a netdev sufficiently generic to be used by people who don't want namespaces but just want to do some network testing, like Ben Greear does. He mentioned in a previous email, he will be happy to stop redirecting people to out of tree patch.

https://lists.linux-foundation.org/pipermail/containers/2007-April/004420.html

Deniel,

Quoted 48 lines · Daniel Lezcano

Quoted 45 lines · Pavel Emelianov

Quoted 10 lines

Quoted 10 lines

I did this at the very first version, but Alexey showed me that this would be wrong. Look. When we create the second device it must be in the other namespace as it is useless to have them in one namespace. But if we have the device in the other namespace the RTNL_NEWLINK message from kernel would come into this namespace thus confusing ip utility in the init namespace. Creating the device in the init ns and moving it into the new one is rather a complex task.

Quoted 6 lines

Pavel,

moving the netdevice to another namespace is not a complex task. Eric Biederman did it in its patchset ( cf. http://lxc.sf.net/network )

By saying complex I didn't mean that this is difficult to implement, but that it consists (must consist) of many stages. I.e. composite. Making the device right in the namespace is liter.

Quoted 4 lines

When the pair device is created, both extremeties are into the init namespace and you can choose to which namespace to move one extremity.

I do not mind that.

Quoted 4 lines

When the network namespace dies, the netdev is moved back to the init namespace.
That facilitate network device management.

Quoted 8 lines

Concerning netlink events, this is automatically generated when the network device is moved through namespaces.

IMHO, we should have the network device movement between namespaces in order to be able to move a physical network device too (eg. you have 4 NIC and you want to create 3 containers and assign 3 NIC to each of them)

Agree. Moving the devices is a must-have functionality.

Quoted 9 lines

Quoted 5 lines

I do not mind making the pair in the init namespace and move the second one into the desired namespace. But if we *always* will have two ends in different namespaces what to complicate things for?

Just to provide a netdev sufficiently generic to be used by people who don't want namespaces but just want to do some network testing, like Ben Greear does. He mentioned in a previous email, he will be happy to stop redirecting people to out of tree patch.

https://lists.linux-foundation.org/pipermail/containers/2007-April/004420.html

no one is against generic code and ability to create 2 interfaces in *one* namespace. (Like we currently allow to do so in OpenVZ)

However, believe me, moving an interface is a *hard* operation. Much harder then netdev register from the scratch.

Because it requires to take into account many things like:
- packets in flight which requires synchronize and is slow on big machines
- asynchronous sysfs entries registration/deregistration from rtln_unlock -> netdev_run_todo
- name/ifindex collisions
- shutdown/cleanup of addresses/routes/qdisc and other similar stuff

Quoted 40 lines · Pavel Emelianov

Quoted 8 lines

Quoted 8 lines

I did this at the very first version, but Alexey showed me that this would be wrong. Look. When we create the second device it must be in the other namespace as it is useless to have them in one namespace. But if we have the device in the other namespace the RTNL_NEWLINK message from kernel would come into this namespace thus confusing ip utility in the init namespace. Creating the device in the init ns and moving it into the new one is rather a complex task.

Quoted 5 lines

Pavel,

moving the netdevice to another namespace is not a complex task. Eric Biederman did it in its patchset ( cf. http://lxc.sf.net/network )

By saying complex I didn't mean that this is difficult to implement, but that it consists (must consist) of many stages. I.e. composite. Making the device right in the namespace is liter.

Quoted 3 lines

When the pair device is created, both extremeties are into the init namespace and you can choose to which namespace to move one extremity.

I do not mind that.

Quoted 4 lines

When the network namespace dies, the netdev is moved back to the init namespace.
That facilitate network device management.

Quoted 8 lines

Concerning netlink events, this is automatically generated when the network device is moved through namespaces.

IMHO, we should have the network device movement between namespaces in order to be able to move a physical network device too (eg. you have 4 NIC and you want to create 3 containers and assign 3 NIC to each of them)

Agree. Moving the devices is a must-have functionality.

Quoted 4 lines

I do not mind making the pair in the init namespace and move the second one into the desired namespace. But if we *always* will have two ends in different namespaces what to complicate things for?

Just to provide a netdev sufficiently generic to be used by people who don't want namespaces but just want to do some network testing, like Ben Greear does. He mentioned in a previous email, he will be happy to stop redirecting people to out of tree patch.

https://lists.linux-foundation.org/pipermail/containers/2007-April/004420.html

Quoted 4 lines

Thanks,
Pavel

-
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 9 lines

no one is against generic code and ability to create 2 interfaces in *one* namespace.
(Like we currently allow to do so in OpenVZ)

However, believe me, moving an interface is a *hard* operation. Much harder then netdev
register from the scratch.

Quoted 9 lines

Because it requires to take into account many things like:
- packets in flight which requires synchronize and is slow on big machines
- asynchronous sysfs entries registration/deregistration from rtln_unlock -> netdev_run_todo
- name/ifindex collisions
- shutdown/cleanup of addresses/routes/qdisc and other similar stuff

All of what you are describing is already implemented in the Eric's patchset.

You can have a look at :

http://lxc.sourceforge.net/patches/2.6.20/2.6.20-netns1/broken_out/

And more precisly:

for sysfs issues:
http://lxc.sourceforge.net/patches/2.6.20/2.6.20-netns1/broken_out/0065-sysfs-Shadow-directory-support.patch

for network device movement:
http://lxc.sourceforge.net/patches/2.6.20/2.6.20-netns1/broken_out/0096-net-Implment-network-device-movement-between-namesp.patch

Thanks,
Daniel
-
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 38 lines · Daniel Lezcano

Quoted 37 lines · Pavel Emelianov

Quoted 8 lines

Quoted 8 lines

I did this at the very first version, but Alexey showed me that this would be wrong. Look. When we create the second device it must be in the other namespace as it is useless to have them in one namespace. But if we have the device in the other namespace the RTNL_NEWLINK message from kernel would come into this namespace thus confusing ip utility in the init namespace. Creating the device in the init ns and moving it into the new one is rather a complex task.

Quoted 5 lines

Pavel,

moving the netdevice to another namespace is not a complex task. Eric Biederman did it in its patchset ( cf. http://lxc.sf.net/network )

By saying complex I didn't mean that this is difficult to implement, but that it consists (must consist) of many stages. I.e. composite. Making the device right in the namespace is liter.

Quoted 3 lines

When the pair device is created, both extremeties are into the init namespace and you can choose to which namespace to move one extremity.

I do not mind that.

Quoted 4 lines

When the network namespace dies, the netdev is moved back to the init namespace.
That facilitate network device management.

Quoted 8 lines

Concerning netlink events, this is automatically generated when the network device is moved through namespaces.

IMHO, we should have the network device movement between namespaces in order to be able to move a physical network device too (eg. you have 4 NIC and you want to create 3 containers and assign 3 NIC to each of them)

Agree. Moving the devices is a must-have functionality.

Quoted 8 lines

Quoted 4 lines

I do not mind making the pair in the init namespace and move the second one into the desired namespace. But if we *always* will have two ends in different namespaces what to complicate things for?

Just to provide a netdev sufficiently generic to be used by people who don't want namespaces but just want to do some network testing, like Ben Greear does. He mentioned in a previous email, he will be happy to stop redirecting people to out of tree patch.

This patch creates booth devices in the init namespace. That's what you want, isn't it? When we have the namespaces we will be able to create the pair with booth ends in the init namespace - just do not specify the namespace id to create the 2nd end in and the driver will leave it int the init one.

Quoted 6 lines · Patrick McHardy

Quoted 6 lines

drivers/net/veth.c new file +6 -0

+	skb->pkt_type = PACKET_HOST;
+	skb->protocol = eth_type_trans(skb, rcv);
+	if (dev->features & NETIF_F_NO_CSUM)
+		skb->ip_summed = rcv_priv->ip_summed;
+
+	dst_release(skb->dst);

Quoted 8 lines

drivers/net/veth.c line 161

Quoted 4 lines

drivers/net/veth.c new file +4 -0

+	skb->dst = NULL;
+
+	secpath_reset(skb);
+	nf_reset(skb);

Is skb->mark supposed to survive communication between different namespaces?

I guess it must not. Thanks.

Quoted 5 lines

The rtnl_link codes looks fine. I don't like the VETH_INFO_MAC attribute very much though, we already have a generic device attribute for MAC addresses. Of course that only allows you to supply one MAC address, so I'm wondering what you think of allocating only a single device per newlink operation and binding them in a seperate enslave operation?

I did this at the very first version, but Alexey showed me that this would be wrong. Look. When we create the second device it must be in the other namespace as it is useless to have them in one namespace. But if we have the device in the other namespace the RTNL_NEWLINK message from kernel would come into this namespace thus confusing ip utility in the init namespace. Creating the device in the init ns and moving it into the new one is rather a complex task.

But with such approach the creation looks really logical. We send a packet to the kernel and have a single response about the new device appearance. At the same time we have a RTNL_NEWLINK message arrived at the destination namespace informing that a new device has appeared there as well.

Quoted 11 lines

include/net/veth.h line 11

Quoted 8 lines

include/net/veth.h new file +8 -0

+enum {
+	VETH_INFO_UNSPEC,
+	VETH_INFO_MAC,
+	VETH_INFO_PEER,
+	VETH_INFO_PEER_MAC,
+
+	VETH_INFO_MAX
+};

Please follow the

Quoted 3 lines

#define VETH_INFO_MAX (__VETH_INFO_MAX - 1)

convention here.

Could you please clarify this point. I saw the lines

enum {
	...
	RTNL_NEWLINK
#define RTNL_NEWLINK RTNL_NEWLINK
	...
}

and had my brains exploded imagining what this would mean :(

Quoted 17 lines · Pavel Emelianov

Quoted 13 lines · Patrick McHardy

drivers/net/veth.c line 161

Quoted 10 lines

drivers/net/veth.c new file +10 -0

+	skb->pkt_type = PACKET_HOST;
+	skb->protocol = eth_type_trans(skb, rcv);
+	if (dev->features & NETIF_F_NO_CSUM)
+		skb->ip_summed = rcv_priv->ip_summed;
+
+	dst_release(skb->dst);
+	skb->dst = NULL;
+
+	secpath_reset(skb);
+	nf_reset(skb);

Is skb->mark supposed to survive communication between different namespaces?

Quoted 1 line

I guess it must not. Thanks.

I guess there are a few others that should be cleared as well, like the tc related members, secmark, ipvs_property, ...

Quoted 14 lines

Quoted 5 lines

The rtnl_link codes looks fine. I don't like the VETH_INFO_MAC attribute very much though, we already have a generic device attribute for MAC addresses. Of course that only allows you to supply one MAC address, so I'm wondering what you think of allocating only a single device per newlink operation and binding them in a seperate enslave operation?

I did this at the very first version, but Alexey showed me that this would be wrong. Look. When we create the second device it must be in the other namespace as it is useless to have them in one namespace. But if we have the device in the other namespace the RTNL_NEWLINK message from kernel would come into this namespace thus confusing ip utility in the init namespace. Creating the device in the init ns and moving it into the new one is rather a complex task.

Quoted 5 lines

But with such approach the creation looks really logical. We send a packet to the kernel and have a single response about the new device appearance. At the same time we have a RTNL_NEWLINK message arrived at the destination namespace informing that a new device has appeared there as well.

The question is how to proceed. I haven't read all mails yet, but it seems there is some disagreement about whether to create all devices in the same namespace and move them later or create them directly in

their target namespace. For now I guess it doesn't matter much, so can everyone agree to adding a IFLA_PARTNER attribute that includes a complete ifinfomsg and the attributes and you later decide how to handle namespaces?

Quoted 14 lines

Quoted 10 lines

include/net/veth.h line 11

Quoted 8 lines

include/net/veth.h new file +8 -0

+enum {
+	VETH_INFO_UNSPEC,
+	VETH_INFO_MAC,
+	VETH_INFO_PEER,
+	VETH_INFO_PEER_MAC,
+
+	VETH_INFO_MAX
+};

Please follow the

Quoted 3 lines

#define VETH_INFO_MAX (__VETH_INFO_MAX - 1)

convention here.

Quoted 8 lines

Could you please clarify this point. I saw the lines

enum {
	...
	RTNL_NEWLINK
#define RTNL_NEWLINK RTNL_NEWLINK
	...
}

and had my brains exploded imagining what this would mean :(

Thats just to make the new attributes visible as preprocessor symbols so userspace can use them for #ifdefs. We usually use it when adding new attributes/message types, but its not necessary for the initial set of attributes if you already have some other preprocessor-visisble symbol (like VETH_INFO_MAX) userspace can use.

What I was refering to is this convention:

enum {
...

        __IFLA_MAX
};

#define IFLA_MAX (__IFLA_MAX - 1)

Which is used to make sure that IFLA_MAX is really the max and not max + 1 and additionally people won't forget to update it.

Quoted 3 lines · Patrick McHardy

The question is how to proceed. I haven't read all mails yet, but it seems there is some disagreement about whether to create all devices in the same namespace and move them later or create them directly in

The agreement was that we can make any of the above. We can create booth devices in the init namespace and then move one of them into the desired namespace, or we can explicitly specify which namespace to create the pair in.

Quoted 6 lines · Pavel Emelianov

Quoted 3 lines · Patrick McHardy

The question is how to proceed. I haven't read all mails yet, but it seems there is some disagreement about whether to create all devices in the same namespace and move them later or create them directly in

Quoted 4 lines

The agreement was that we can make any of the above. We can create booth devices in the init namespace and then move one of them into the desired namespace, or we can explicitly specify which namespace to create the pair in.

I'm going to push my latest patches to Dave today, the easiest way is probably is you just add whatever you need to the API afterwards.

Quoted 3 lines · Patrick McHardy

I'm going to push my latest patches to Dave today, the easiest way is probably is you just add whatever you need to the API afterwards.

OK. Dave didn't object against the driver. Hope he will accept it as well.

I have also found a BUG in your API. Look, when you declare the alias with the MODULE_ALIAS_RTNL_LINK in drivers you use strings as an argument. But this macro stringifyes the argument itself which results in bad aliases.

Signed-off-by Pavel Emelianov <[email protected]>

---

include/net/rtnetlink.h +0 -0

index d744198..f627e1f 100644