Virtual ethernet device (tunnel)
Subsystems (2)
PATCH 1/1 Virtual ethernet device (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 is closer to the OpenVZ one and it lacks some unimportant features of etun driver (like ethtool_ops) for simplicity.
The general difference from etun is that a netlink interface is used to create and destroy the pairs. The patch for an ip utility is also provided.
---
drivers/net/Kconfig +6 -0
@@ -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
@@ -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 +387 -0
387 lines not on this page · raw message
include/net/veth.h new file +20 -0
@@ -0,0 +1,20 @@ +#ifndef __NET_VETH_H__ +#define __NET_VETH_H__ + +enum { +VETH_CMD_UNSPEC , +VETH_CMD_ADD , +VETH_CMD_DEL , + +VETH_CMD_MAX +}; + +enum { +VETH_ATTR_UNSPEC , +VETH_ATTR_DEVNAME , +VETH_ATTR_PEERNAME , + +VETH_ATTR_MAX +}; + +#endif
PATCH 1/1 Make ip utility veth driver aware
The new command is called "veth" with the following syntax:
* ip veth add <dev1> <dev2>
creates interconnected pair of veth devices.
* ip veth del <dev>
destroys the pair of veth devices, where <dev> is either <dev1> or <dev2> used to create the pair.
One question that is to be solved is whether or not to create a hard-coded netlink family for veth driver. Without it the family resolution code has to be moved to general place in ip utility (by now it is copy-paste-ed from one file to another till final decision).
---
ip/Makefile +1 -1
@@ -1,7 +1,7 @@ IPOBJ=ip.o ipaddress.o iproute.o iprule.o \ rtm_map.o iptunnel.o ip6tunnel.o tunnel.o ipneigh.o ipntable.o iplink.o \ ipmaddr.o ipmonitor.o ipmroute.o ipprefix.o \ - ipxfrm.o xfrm_state.o xfrm_policy.o xfrm_monitor.o + ipxfrm.o xfrm_state.o xfrm_policy.o xfrm_monitor.o veth.o RTMONOBJ=rtmon.o
ip/ip.c +3 -1
@@ -27,6 +27,7 @@#include "SNAPSHOT.h" #include "utils.h" #include "ip_common.h" +#include "veth.h" int preferred_family =AF_UNSPEC ;int show_stats =0 ;
@@ -46,7 +47,7 @@ static void usage(void)"Usage: ip [ OPTIONS ] OBJECT { COMMAND | help }\n" " ip [ -force ] [-batch filename\n" "where OBJECT := { link | addr | route | rule | neigh | ntable | tunnel |\n" -" maddr | mroute | monitor | xfrm }\n" +" maddr | mroute | monitor | xfrm | veth }\n" " OPTIONS := { -V[ersion] | -s[tatistics] | -r[esolve] |\n" " -f[amily] { inet | inet6 | ipx | dnet | link } |\n" " -o[neline] | -t[imestamp] }\n");
@@ -76,6 +77,7 @@ static const struct cmd { { "monitor", do_ipmonitor }, { "xfrm", do_xfrm }, { "mroute", do_multiroute }, + { "veth", do_veth }, { "help", do_help }, { 0 } };
ip/veth.c new file +196 -0
196 lines not on this page · raw message
ip/veth.h new file +17 -0
@@ -0,0 +1,17 @@ +int do_veth (int argc,char **argv); + +enum { +VETH_CMD_UNSPEC , +VETH_CMD_ADD , +VETH_CMD_DEL , + +VETH_CMD_MAX +}; + +enum { +VETH_ATTR_UNSPEC , +VETH_ATTR_DEVNAME , +VETH_ATTR_PEERNAME , + +VETH_ATTR_MAX +};
Quoted 7 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.
Quoted 8 lines
Eric recently sent a similar driver called etun. This implementation is closer to the OpenVZ one and it lacks some unimportant features of etun driver (like
ethtool_ops) for simplicity.The general difference from etun is that a netlink interface is used to create and destroy the pairs. The patch for an ip utility is also provided.
if etun and veth are similar, why didn't you put the netlink interface to the etun driver instead of sending a new driver ?
-- Daniel
Quoted 13 lines · Daniel Lezcano
Quoted 12 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 is closer to the OpenVZ one and it lacks some unimportant features of etun driver (like
ethtool_ops) for simplicity.
Quoted 5 lines
Quoted 3 lines
The general difference from etun is that a netlink interface is used to create and destroy the pairs. The patch for an ip utility is also provided.
if etun and veth are similar, why didn't you put the netlink interface to the etun driver instead of sending a new driver ?
Alexey said, that he preferred the name "veth" to "etun". So an incremental patch would look too bad.
Quoted 6 lines
-- 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 7 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.
Quoted 8 lines
Eric recently sent a similar driver called etun. This implementation is closer to the OpenVZ one and it lacks some unimportant features of etun driver (like
ethtool_ops) for simplicity.The general difference from etun is that a netlink interface is used to create and destroy the pairs. The patch for an ip utility is also provided.
Thats a lot better than using sysfs, but I think it would be preferrable to use rtnetlink instead of genetlink for network configuration.
Quoted 3 lines · Patrick McHardy
Thats a lot better than using sysfs, but I think it would be preferrable to use rtnetlink instead of genetlink for network configuration.
or you can just hold rtnl while using genl.
I do agree it would be easier to just use rtnetlink ...
cheers,
jamal
Quoted 10 lines · jamal
Quoted 3 lines · Patrick McHardy
Thats a lot better than using sysfs, but I think it would be preferrable to use rtnetlink instead of genetlink for network configuration.
or you can just hold rtnl while using genl.
I do agree it would be easier to just use rtnetlink ...
The rtnl needs to be held in either case, but using a different netlink family introduces races in message processing. For example a simple:
ip link add dev veth0
ip route add 10.0.0.0/8 dev veth0
might fail because we have two different input queues and the routing message might get processed before the link message.
Quoted 17 lines · Patrick McHardy
Quoted 10 lines · jamal
Quoted 3 lines · Patrick McHardy
Thats a lot better than using sysfs, but I think it would be preferrable to use rtnetlink instead of genetlink for network configuration.
or you can just hold rtnl while using genl.
I do agree it would be easier to just use rtnetlink ...The rtnl needs to be held in either case, but using a different netlink family introduces races in message processing. For example a simple:
Quoted 5 lines
ip link add dev veth0
ip route add 10.0.0.0/8 dev veth0might fail because we have two different input queues and the routing message might get processed before the link message.
The consensus from the last thread was pretty much that we need to implement RTM_NEWLINK and RTM_DELLINK, if it is at all possible.
So that we can get code reuse between different virtual devices. Although I suspect we will need some per type attribute parsing.
Eric
Quoted 2 lines · Eric W. Biederman
The consensus from the last thread was pretty much that we need to implement
RTM_NEWLINKandRTM_DELLINK, if it is at all possible.
Yes, as I said, I can take care of this for 2.6.23.
Quoted 2 lines
So that we can get code reuse between different virtual devices. Although I suspect we will need some per type attribute parsing.
Yes, we could use IFLA_PROTINFO, but since some devices (for example bridging) already use a non-nested attribute for this when sending notifications, its probably better to introduce a new attribute for device specific stuff to keep things symetrical.
Quoted 11 lines · On Wed, 02 May 2007 14:54:51 +0400 Pavel Emelianov <[email protected]> wrote:
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 is closer to the OpenVZ one and it lacks some unimportant features of etun driver (like
ethtool_ops) for simplicity.
The ethtool stuff lets bonding and bridging work better.
Quoted 12 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 is closer to the OpenVZ one and it lacks some unimportant features of etun driver (like
ethtool_ops) for simplicity.
Quoted 9 lines
The general difference from etun is that a netlink interface is used to create and destroy the pairs. The patch for an ip utility is also provided.
Signed-off-by Pavel Emelianov <[email protected]>Acked-by Kirill Korotaev <[email protected]>Acked-by Dmitry Mishin <[email protected]>Acked-by Alexey Kuznetsov <[email protected]>
In your veth_xmit method, do you perhaps also need to initialize skb->mark to zero?
Quoted 18 lines
drivers/net/veth.c new file +17
-0+static int veth_create_pair (char *name,char *peer_name) +{ +struct net_device *dev; +struct net_device *peer; +struct veth_struct *dev_veth; +struct veth_struct *peer_veth; +int err; + + dev =veth_dev_start (name); +if (IS_ERR (dev)) { + err =PTR_ERR (dev); + goto err; + } + + peer =veth_dev_start (peer_name); +if (IS_ERR (peer)) { + err =PTR_ERR (peer);
drivers/net/veth.c line 207
Quoted 10 lines
drivers/net/veth.c new file +10
-0+ goto err_peer; + } + + dev_veth = dev->priv; + peer_veth = peer->priv; + + dev_veth->peer = peer; + dev_veth->dev = dev; + peer_veth->peer = dev; + peer_veth->dev = peer;
It looks like you add it to netdev list before you set up the peer, so it could race and crash on stale/null peer pointers?
drivers/net/veth.c line 213
Quoted 7 lines
drivers/net/veth.c new file +6
-0+ +rtnl_lock (); +list_add (&dev_veth->list, &veth_list); +INIT_LIST_HEAD (&peer_veth->list); +rtnl_unlock (); +return 0 ;
Seems to me you might want get all of your state and internal list setup completed before you register it with the netdev list, though I'm not sure it matters in this case.
Signature · 1 line
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com