Virtual ethernet tunnel (v.2)

The usage is

# ip link add [name] type veth [peer <name>] [mac <mac>] [peer_mac <mac>]

This version doesn't include the fix for ip/iplink.c as Patrick said that he had included it into his patches already.

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

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.

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

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

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

+
+	rcv_priv = netdev_priv(rcv);
+	skb->pkt_type = PACKET_HOST;
+	skb->protocol = eth_type_trans(skb, rcv);

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

+
+	stats->tx_bytes += length;
+	stats->tx_packets++;
 
+
+	stats = per_cpu_ptr(rcv_priv->stats, cpu);
+	stats->rx_bytes += length;

Quoted 4 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.

As Dave mentioned, there is already a driver known as 'veth'. Maybe borrow the etun name as well?

I would also like some way to identify veth from other device types, preferably
something like a value in sysfs. However, that should not hold up

consideration of
this patch, and I am willing to submit a patch after this goes in to add the functionality
I want...

Quoted 11 lines

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

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

drivers/net/veth.c line 161

Quoted 10 lines

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

+
+    skb_orphan(skb);
+
+    priv = netdev_priv(dev);
+    cpu = smp_processor_id();
+    stats = per_cpu_ptr(priv->stats, cpu);
+    rcv = priv->peer;
+
+    if (!(rcv->flags & IFF_UP))
+        goto outf;

I think you need at least the option to zero out the time-stamp, otherwise it will
not be re-calculated when received on the peer, and it potentially spent significant
time since it was last calculated (think netem delay or similar).

(quoted diff) +5 -0

+        /* Zero out the time-stamp so that receiving code is forced
+         * to recalculate it.
+         */
+        skb->tstamp.off_sec = 0;
+        skb->tstamp.off_usec = 0;

Quoted 11 lines

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

+
+    rcv_priv = netdev_priv(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;
+    secpath_reset(skb);

drivers/net/veth.c line 175

Quoted 5 lines

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

+    nf_reset(skb);
+    skb->mark = 0;
+
+    length = skb->len;

This should be done before you do the eth_type_trans, as that pulls the header and your
byte counters will be off.

Quoted 7 lines

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

+
+    stats->tx_bytes += length;
+    stats->tx_packets++;
  +
+    stats = per_cpu_ptr(rcv_priv->stats, cpu);
+    stats->rx_bytes += length;

drivers/net/veth.c line 191

Quoted 10 lines

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

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

Thanks,
Ben

Quoted 7 lines · Ben Greear

Quoted 5 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.

Quoted 3 lines

As Dave mentioned, there is already a driver known as 'veth'. Maybe borrow the etun name as well?

We have already seen that this driver uses ethXXX names for its devices and Dave agreed with veth one. Moreover Alexey Kuznetsov said that he would prefer the name veth for etun.

Quoted 5 lines

I would also like some way to identify veth from other device types, preferably
something like a value in sysfs. However, that should not hold up

We can do this with ethtool. It can get and print the driver name of the device.

Quoted 24 lines

I think you need at least the option to zero out the time-stamp, otherwise it will
not be re-calculated when received on the peer, and it potentially spent significant
time since it was last calculated (think netem delay or similar).

(quoted diff) +5 -0

+        /* Zero out the time-stamp so that receiving code is forced
+         * to recalculate it.
+         */
+        skb->tstamp.off_sec = 0;
+        skb->tstamp.off_usec = 0;

Quoted 13 lines

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

+
+    rcv_priv = netdev_priv(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;
+    secpath_reset(skb);
+    nf_reset(skb);

Quoted 9 lines

drivers/net/veth.c line 175

Quoted 5 lines

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

+    skb->mark = 0;
+
+    length = skb->len;

This should be done before you do the eth_type_trans, as that pulls the header and your
byte counters will be off.

This will be ETH_HLEN larger, do you mean this? I think this is normal as this device tries to look like an "iron" ethernet card :)

Quoted 8 lines · Pavel Emelianov

Quoted 6 lines · Ben Greear

Quoted 4 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.

Quoted 9 lines

Quoted 4 lines

As Dave mentioned, there is already a driver known as 'veth'. Maybe borrow
the etun name as well?

We have already seen that this driver uses ethXXX names for its devices and Dave agreed with veth one. Moreover Alexey Kuznetsov said that he would prefer the name veth for etun.

Ok, fine by me. I started reading mail from the wrong direction this morning :)

Quoted 9 lines

Quoted 5 lines

I would also like some way to identify veth from other device types, preferably
something like a value in sysfs. However, that should not hold up

We can do this with ethtool. It can get and print the driver name of the device.

I think I'd like something in sysfs that we could query for any interface. Possible return
strings could be:
VLAN
VETH
ETH
PPP
BRIDGE
AP /* wifi access point interface */
STA /* wifi station */
....

I will cook up a patch for consideration after veth goes in.

Quoted 33 lines

Quoted 32 lines

I think you need at least the option to zero out the time-stamp, otherwise it will
not be re-calculated when received on the peer, and it potentially spent significant
time since it was last calculated (think netem delay or similar).

(quoted diff) +5 -0

+        /* Zero out the time-stamp so that receiving code is forced
+         * to recalculate it.
+         */
+        skb->tstamp.off_sec = 0;
+        skb->tstamp.off_usec = 0;

Quoted 7 lines

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

+
+    rcv_priv = netdev_priv(rcv);
+    skb->pkt_type = PACKET_HOST;
+    skb->protocol = eth_type_trans(skb, rcv);

drivers/net/veth.c line 175

Quoted 10 lines

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

+    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);
+    skb->mark = 0;
+
+    length = skb->len;

This should be done before you do the eth_type_trans, as that pulls the header and your
byte counters will be off.

Quoted 3 lines

This will be ETH_HLEN larger, do you mean this? I think this is normal as this device tries to look like an "iron" ethernet card :)

For device counters, it should count the number of bytes received, including all headers,
but excluding the ethernet FCS. If an 'iron' card did differently, I'd
consider it a bug.

Thanks,
Ben

Hmm... The loopback must be doing bad things then. It first calls eth_type_trans and then accounts for the new skb->len.

Quoted 8 lines

Quoted 4 lines

I would also like some way to identify veth from other device types, preferably
something like a value in sysfs. However, that should not hold up

We can do this with ethtool. It can get and print the driver name of the device.

I think I'd like something in sysfs that we could query for any interface. Possible return
strings could be:
VLAN
VETH
ETH
PPP
BRIDGE
AP /* wifi access point interface */
STA /* wifi station */
....

I will cook up a patch for consideration after veth goes in.

Ben Greear wrote:

[snip]

Quoted 21 lines

Quoted 9 lines

Quoted 5 lines

I would also like some way to identify veth from other device types, preferably
something like a value in sysfs. However, that should not hold up

We can do this with ethtool. It can get and print the driver name of the device.

I think I'd like something in sysfs that we could query for any interface. Possible return
strings could be:
VLAN
VETH
ETH
PPP
BRIDGE
AP /* wifi access point interface */
STA /* wifi station */
....

Quoted 3 lines

I will cook up a patch for consideration after veth goes in.

Ben, could you please tell what sysfs features do you plan to implement?

I have another sysfs patch that allows setting a default skb->mark for an interface so that you can set the skb->mark
before it hits the connection tracking logic, but I'm been told this one has very little chance
of getting into the kernel. The skb->mark patch is only useful (as far

as I can tell) if you
also include a patch Patrick McHardy did for me that allowed the conn-tracking logic to
use skb->mark as part of it's tuple. This allows me to do NAT between virtual routers
(routing tables) on the same machine using veth-equivalent drivers to connect the
routers. He thinks this will probably not ever get into the kernel either.

Quoted 5 lines · Ben Greear

I have another sysfs patch that allows setting a default skb->mark for an interface so that you can set the skb->mark
before it hits the connection tracking logic, but I'm been told this one has very little chance
of getting into the kernel. The skb->mark patch is only useful (as far

Quoted 8 lines

as I can tell) if you
also include a patch Patrick McHardy did for me that allowed the conn-tracking logic to
use skb->mark as part of it's tuple. This allows me to do NAT between virtual routers
(routing tables) on the same machine using veth-equivalent drivers to connect the
routers. He thinks this will probably not ever get into the kernel either.

Are these patches available somewhere? I'm currently doing NAT between virtual routers by some advanced iproute2/iptables trickery, but I have no way to handle the occasional tuple conflict.

Regards,
Carl-Daniel

Quoted 9 lines · Pavel Emelianov

Quoted 4 lines

I would also like some way to identify veth from other device types, preferably
something like a value in sysfs. However, that should not hold up

We can do this with ethtool. It can get and print the driver name of the device.

I think I'd like something in sysfs that we could query for any interface. Possible return
strings could be:
VLAN
VETH
ETH
PPP
BRIDGE
AP /* wifi access point interface */
STA /* wifi station */
....

I will cook up a patch for consideration after veth goes in.