Network Checksum Removal

PATCH In review Jon Mason 6 participants 27 messages May 20, 2005 – May 24, 2005

Subsystems (2)

Networking Xen hypervisor interface

lore

Share & tools

lore

Jon Mason

author

2005-05-20 23:30 UTC #0 lore raw

PATCH 1/1 Network Checksum Removal

Currently in Xen, interdomain communication needlessly wastes CPU cycles calculating and verifying TCP/UDP checksums. This is unnecessary, as the possibility of packet corruption between domains is miniscule (and can be detected in memory via ECC). Also, domU's are unable to take advantage of any adapter hardware checksum offload capabilities when transmitting packets outside of the system.

This patch removes the inter-xen network checksums by using the existing Linux hardware checksum offload infrastructure. This decreased the changes needed by this patch, and enabled me to easily use hardware checksum on the physical
devices.

Here is how the traffic flow now works (generically):
Traffic generated by dom0 will not do the TCP/UDP checksums and will notify domU this via the csum bit in netif_rx_response_t. domU will check for the csum bit on each incoming packet, and if not enabled it will verify the checksum.

Traffic generated externally, if rx hardware checksum is available and enabled, then dom0 will notify domU that it is unnecessary to validate this checksum (providing the checksum is valid) by enabling the csum bit. If domU is not notified that it is unnecessary to vaildate the checksum, then domU will do it.

Traffic generated by domU will not do the TCP/UDP checksums and will notify dom0 this via the csim bit in netif_tx_request_t. dom0 will check for the csum bit on each incoming packet, and if enabled it will calculate the necessary bits for hardware checksum offload (skb->csum, which is the offset to insert the checksum). It also sets skb->ip_summed = CHECKSUM_UNNECESSARY;
skb->flags |= SKB_FDW_NO_CSUM;

ip_summed is set in the case that the packet is destined for dom0, which will prevent dom0 from checking the TCP/UDP checksum. Unfortunately, this flag is stomped on by both routing and bridging. So I added a new skb field and a new flag, SKB_FDW_NO_CSUM. This field is checked on transmission and corrects the fields that have been modified by the bridging/routing code. Once these fields have been corrected, the adapter (if tx csum able) or stack (via skb_checksum_help()) will calculate the TCP/UDP checksum.

Performance:
I ran the following test cases with netperf3 TCP_STREAM, and get the following boosts (using bridging):
domU->dom0 500Mbps
dom0->domU 10Mbps
domU->remote host none
domU->domU 70Mbps
Note: I have a small bridging patch which increases dom0 throughput. I am in the process of having it accepted into the Linux kernel.

I currently do not have CPU utilization numbers (where the real boost of this patch would be), and I do not have throughput numbers for routing/nat.

Also, I added the ability to enable/disable checksum offload via the ethtool command.

Signed-off-by Jon Mason <[email protected]>

include/public/io/netif.h renamed from xen-unstable-pristine/xen/include/public/io/netif.h +4 -2

@@ -12,7 +12,8 @@
 typedef struct {
     memory_t addr;   /*  0: Machine address of packet.  */
     MEMORY_PADDING;
-    u16      id;     /*  8: Echoed in response message. */
+    u16      csum:1;
+    u16      id:15;     /*  8: Echoed in response message. */
     u16      size;   /* 10: Packet size in bytes.       */
 } PACKED netif_tx_request_t; /* 12 bytes */

@@ -29,7 +30,8 @@ typedef struct {
 typedef struct {
     memory_t addr;   /*  0: Machine address of packet.              */
     MEMORY_PADDING;
-    u16      id;     /*  8:  */
+    u16      csum:1;
+    u16      id:15;     /*  8:  */
     s16      status; /* 10: -ve: BLKIF_RSP_* ; +ve: Rx'ed pkt size. */
 } PACKED netif_rx_response_t; /* 12 bytes */

drivers/xen/netback/netback.c renamed from xen-unstable-pristine/linux-2.6.11-xen-sparse/drivers/xen/netback/netback.c +19 -0

@@ -13,6 +13,9 @@
 #include "common.h"
 #include <asm-xen/balloon.h>
 #include <asm-xen/evtchn.h>
+#include <net/ip.h>
+#include <linux/tcp.h>
+#include <linux/udp.h>
 
 #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,0)
 #include <linux/delay.h>

@@ -154,10 +157,14 @@ int netif_be_start_xmit(struct sk_buff *
         __skb_put(nskb, skb->len);
         (void)skb_copy_bits(skb, -hlen, nskb->data - hlen, skb->len + hlen);
         nskb->dev = skb->dev;
+	nskb->ip_summed = skb->ip_summed;
         dev_kfree_skb(skb);
         skb = nskb;
     }
 
+    if (skb->ip_summed > 0)
+	netif->rx->ring[MASK_NETIF_RX_IDX(netif->rx_resp_prod)].resp.csum = 1;
+	
     netif->rx_req_cons++;
     netif_get(netif);

@@ -646,6 +653,18 @@ static void net_tx_action(unsigned long 
         skb->dev      = netif->dev;
         skb->protocol = eth_type_trans(skb, skb->dev);
 
+	skb->csum = 0;
+	if (txreq.csum) {
+		skb->ip_summed = CHECKSUM_UNNECESSARY;
+		skb->flags |= SKB_FDW_NO_CSUM;
+		skb->nh.iph = (struct iphdr *) skb->data;
+		if (skb->nh.iph->protocol == IPPROTO_TCP)
+			skb->csum = offsetof(struct tcphdr, check);
+		if (skb->nh.iph->protocol == IPPROTO_UDP)
+			skb->csum = offsetof(struct udphdr, check);
+	} else
+		skb->ip_summed = CHECKSUM_NONE;
+
         netif->stats.rx_bytes += txreq.size;
         netif->stats.rx_packets++;

drivers/xen/netback/interface.c renamed from xen-unstable-pristine/linux-2.6.11-xen-sparse/drivers/xen/netback/interface.c +1 -0

@@ -159,6 +159,7 @@ void netif_create(netif_be_create_t *cre
     dev->get_stats       = netif_be_get_stats;
     dev->open            = net_open;
     dev->stop            = net_close;
+    dev->features        = NETIF_F_NO_CSUM;
 
     /* Disable queuing. */
     dev->tx_queue_len = 0;

drivers/xen/netfront/netfront.c renamed from xen-unstable-pristine/linux-2.6.11-xen-sparse/drivers/xen/netfront/netfront.c +13 -1

@@ -40,6 +40,7 @@
 #include <linux/init.h>
 #include <linux/bitops.h>
 #include <linux/proc_fs.h>
+#include <linux/ethtool.h>
 #include <net/sock.h>
 #include <net/pkt_sched.h>
 #include <net/arp.h>

@@ -287,6 +288,11 @@ static int send_fake_arp(struct net_devi
     return dev_queue_xmit(skb);
 }
 
+static struct ethtool_ops network_ethtool_ops = {
+	.get_tx_csum = ethtool_op_get_tx_csum,
+	.set_tx_csum = ethtool_op_set_tx_csum,
+};
+
 static int network_open(struct net_device *dev)
 {
     struct net_private *np = netdev_priv(dev);

@@ -472,6 +478,7 @@ static int network_start_xmit(struct sk_
     tx->id   = id;
     tx->addr = virt_to_machine(skb->data);
     tx->size = skb->len;
+    tx->csum = (skb->ip_summed) ? 1 : 0;
 
     wmb(); /* Ensure that backend will see the request. */
     np->tx->req_prod = i + 1;

@@ -572,6 +579,9 @@ static int netif_poll(struct net_device 
         skb->len  = rx->status;
         skb->tail = skb->data + skb->len;
 
+	if (rx->csum)
+		skb->ip_summed = CHECKSUM_UNNECESSARY;
+		
         np->stats.rx_packets++;
         np->stats.rx_bytes += rx->status;

@@ -966,7 +976,9 @@ static int create_netdev(int handle, str
     dev->get_stats       = network_get_stats;
     dev->poll            = netif_poll;
     dev->weight          = 64;
-    
+    dev->features 	 = NETIF_F_IP_CSUM;
+    SET_ETHTOOL_OPS(dev, &network_ethtool_ops);
+
     if ((err = register_netdev(dev)) != 0) {
         printk(KERN_WARNING "%s> register_netdev err=%d\n", __FUNCTION__, err);
         goto exit;

include/linux/skbuff.h renamed from xen-unstable-pristine/linux-2.6.11-xen0/include/linux/skbuff.h +6 -2

@@ -37,6 +37,10 @@
 #define CHECKSUM_HW 1
 #define CHECKSUM_UNNECESSARY 2
 
+#define SKB_CLONED	1
+#define SKB_NOHDR	2
+#define SKB_FDW_NO_CSUM	4
+
 #define SKB_DATA_ALIGN(X)	(((X) + (SMP_CACHE_BYTES - 1)) & \
 				 ~(SMP_CACHE_BYTES - 1))
 #define SKB_MAX_ORDER(X, ORDER)	(((PAGE_SIZE << (ORDER)) - (X) - \

@@ -238,7 +242,7 @@ struct sk_buff {
 				mac_len,
 				csum;
 	unsigned char		local_df,
-				cloned,
+				flags,
 				pkt_type,
 				ip_summed;
 	__u32			priority;

@@ -370,7 +374,7 @@ static inline void kfree_skb(struct sk_b
  */
 static inline int skb_cloned(const struct sk_buff *skb)
 {
-	return skb->cloned && atomic_read(&skb_shinfo(skb)->dataref) != 1;
+	return (skb->flags & SKB_CLONED) && atomic_read(&skb_shinfo(skb)->dataref) != 1;
 }
 
 /**

net/core/skbuff.c renamed from xen-unstable-pristine/linux-2.6.11-xen0/net/core/skbuff.c +4 -4

@@ -240,7 +240,7 @@ static void skb_clone_fraglist(struct sk
 
 void skb_release_data(struct sk_buff *skb)
 {
-	if (!skb->cloned ||
+	if (!(skb->flags & SKB_CLONED) ||
 	    atomic_dec_and_test(&(skb_shinfo(skb)->dataref))) {
 		if (skb_shinfo(skb)->nr_frags) {
 			int i;

@@ -352,7 +352,7 @@ struct sk_buff *skb_clone(struct sk_buff
 	C(data_len);
 	C(csum);
 	C(local_df);
-	n->cloned = 1;
+	n->flags = skb->flags | SKB_CLONED;
 	C(pkt_type);
 	C(ip_summed);
 	C(priority);

@@ -395,7 +395,7 @@ struct sk_buff *skb_clone(struct sk_buff
 	C(end);
 
 	atomic_inc(&(skb_shinfo(skb)->dataref));
-	skb->cloned = 1;
+	skb->flags |= SKB_CLONED;
 
 	return n;
 }

@@ -603,7 +603,7 @@ int pskb_expand_head(struct sk_buff *skb
 	skb->mac.raw += off;
 	skb->h.raw   += off;
 	skb->nh.raw  += off;
-	skb->cloned   = 0;
+	skb->flags    &= SKB_CLONED;
 	atomic_set(&skb_shinfo(skb)->dataref, 1);
 	return 0;

net/core/dev.c renamed from xen-unstable-pristine/linux-2.6.11-xen0/net/core/dev.c +11 -1

@@ -98,6 +98,7 @@
 #include <linux/stat.h>
 #include <linux/if_bridge.h>
 #include <linux/divert.h>
+#include <net/ip.h> 
 #include <net/dst.h>
 #include <net/pkt_sched.h>
 #include <net/checksum.h>

@@ -1182,7 +1183,7 @@ int __skb_linearize(struct sk_buff *skb,
 	skb->data    += offset;
 
 	/* We are no longer a clone, even if we were. */
-	skb->cloned    = 0;
+	skb->flags    &= ~SKB_CLONED;
 
 	skb->tail     += skb->data_len;
 	skb->data_len  = 0;

@@ -1236,6 +1237,15 @@ int dev_queue_xmit(struct sk_buff *skb)
 	    __skb_linearize(skb, GFP_ATOMIC))
 		goto out_kfree_skb;
 
+	/* If packet is forwarded to a device that needs a checksum and not 
+	 * checksummed, correct the pointers and enable checksumming in the 
+	 * next function.
+	 */
+	if (skb->flags & SKB_FDW_NO_CSUM) {
+		skb->ip_summed = CHECKSUM_HW;
+		skb->h.raw = (void *)skb->nh.iph + (skb->nh.iph->ihl * 4);
+	}
+
 	/* If packet is not checksummed and device does not support
 	 * checksumming for this protocol, complete checksumming here.
 	 */

Keir Fraser

2005-05-21 14:53 UTC #1 lore raw

Quoted 6 lines · Jon Mason

Traffic generated externally, if rx hardware checksum is available and enabled, then dom0 will notify domU that it is unnecessary to validate this checksum (providing the checksum is valid) by enabling the csum bit. If domU is not notified that it is unnecessary to vaildate the checksum, then domU will do it.

Unfortunately you can't trust the ip_summed flag because, as you point out yourself, the bridge and IP forwarding paths both clobber it to CHECKSUM_NONE. This puts us in a pickle: without hacking in some more info we have no way to know whether the physical interface (eth0, say) summed the packet or not. And, if it did, whether it was a CHECKSUM_UNNECESSARY or a CHECKSUM_HW kind of summing (they differ in how you interpret the result).

Your patch as its stands is only correct if eth0 sets ip_summed==CHECKSUM_UNNECESSARY on received packets.

-- Keir

Keir Fraser

2005-05-21 19:16 UTC #2 lore raw

Quoted 9 lines · Keir Fraser

Quoted 5 lines
Traffic generated externally, if rx hardware checksum is available and enabled, then dom0 will notify domU that it is unnecessary to validate this checksum (providing the checksum is valid) by enabling the csum bit. If domU is not notified that it is unnecessary to vaildate the checksum, then domU will do it.
Unfortunately you can't trust the ip_summed flag because, as you point out yourself, the bridge and IP forwarding paths both clobber it to CHECKSUM_NONE. This puts us in a pickle: without hacking in some more info we have no way to know whether the physical interface (eth0, say) summed the packet or not. And, if it did, whether it was a CHECKSUM_UNNECESSARY or a CHECKSUM_HW kind of summing (they differ in how you interpret the result).
Your patch as its stands is only correct if eth0 sets ip_summed==CHECKSUM_UNNECESSARY on received packets.

I've checked in a modified version of your patch that hopefully deals with propagating checksum information in both directions across a virtual bridge or router. I replaced your skb flags with two new ones -- proto_csum_blank and proto_csum_valid.

The former indicates that the protocol-level checksum needs filling in. This is not a problem for local processing, but the flag is picked up before sending to a physical interface and fixed up.

The latter indicates that the proto-level checksum has been validated since arrival at localhost (*or* that the packet originated from a domU on localhost). This flag survives crossing a bridge/router so we can trust it when deciding if checksum validation is required.

I'll push the patch to the bkbits repository just as soon as bkbits rematerialises. :-)

If you have any performance or stress tests that you were using to test checksum offloading, it would be great to find out how they perform on the checked-in version!

Thanks,
Keir

Jon Mason

author

2005-05-21 21:49 UTC #3 lore raw

Quoted 15 lines · Keir Fraser

Quoted 14 lines · Keir Fraser
Quoted 5 lines
Traffic generated externally, if rx hardware checksum is available and enabled, then dom0 will notify domU that it is unnecessary to validate this checksum (providing the checksum is valid) by enabling the csum bit. If domU is not notified that it is unnecessary to vaildate the checksum, then domU will do it.
Unfortunately you can't trust the ip_summed flag because, as you point out yourself, the bridge and IP forwarding paths both clobber it to CHECKSUM_NONE. This puts us in a pickle: without hacking in some more info we have no way to know whether the physical interface (eth0, say) summed the packet or not. And, if it did, whether it was a CHECKSUM_UNNECESSARY or a CHECKSUM_HW kind of summing (they differ in how you interpret the result).

Quoted 2 lines

Quoted 2 lines
Your patch as its stands is only correct if eth0 sets ip_summed==CHECKSUM_UNNECESSARY on received packets.

Silly mistake on my part. Good catch.

Quoted 9 lines

I've checked in a modified version of your patch that hopefully deals with propagating checksum information in both directions across a virtual bridge or router. I replaced your skb flags with two new ones -- proto_csum_blank and proto_csum_valid.
The former indicates that the protocol-level checksum needs filling in. This is not a problem for local processing, but the flag is picked up before sending to a physical interface and fixed up.

Quoted 7 lines

The latter indicates that the proto-level checksum has been validated since arrival at localhost (*or* that the packet originated from a domU on localhost). This flag survives crossing a bridge/router so we can trust it when deciding if checksum validation is required.
I'll push the patch to the bkbits repository just as soon as bkbits rematerialises. :-)

I'd be interested in seeing the bits you added.

Quoted 3 lines

If you have any performance or stress tests that you were using to test checksum offloading, it would be great to find out how they perform on the checked-in version!

I am happy to give the latest patch some testing (thought I probably won't be able Monday).

Thanks,
Jon

Andrew Theurer

2005-05-23 15:29 UTC #4 lore raw

In reply to Keir Fraser

Quoted 14 lines

I've checked in a modified version of your patch that hopefully deals with propagating checksum information in both directions across a virtual bridge or router. I replaced your skb flags with two new ones -- proto_csum_blank and proto_csum_valid.
The former indicates that the protocol-level checksum needs filling in. This is not a problem for local processing, but the flag is picked up before sending to a physical interface and fixed up.
The latter indicates that the proto-level checksum has been validated since arrival at localhost (*or* that the packet originated from a domU on localhost). This flag survives crossing a bridge/router so we can trust it when deciding if checksum validation is required.

Quoted 6 lines

I'll push the patch to the bkbits repository just as soon as bkbits rematerialises. :-)
If you have any performance or stress tests that you were using to test checksum offloading, it would be great to find out how they perform on the checked-in version!

Now that BK is up, I'll run some netperf tests before/after that changeset and see what we get.

-Andrew

Bin Ren

2005-05-23 15:31 UTC #5 lore raw

It seems to break the interdomain ssh and nfs on my machine. Digging for reasons.

- Bin

Quoted 31 lines · Andrew Theurer

Quoted 14 lines
I've checked in a modified version of your patch that hopefully deals with propagating checksum information in both directions across a virtual bridge or router. I replaced your skb flags with two new ones -- proto_csum_blank and proto_csum_valid.
The former indicates that the protocol-level checksum needs filling in. This is not a problem for local processing, but the flag is picked up before sending to a physical interface and fixed up.
The latter indicates that the proto-level checksum has been validated since arrival at localhost (*or* that the packet originated from a domU on localhost). This flag survives crossing a bridge/router so we can trust it when deciding if checksum validation is required.
Quoted 6 lines
I'll push the patch to the bkbits repository just as soon as bkbits rematerialises. :-)
If you have any performance or stress tests that you were using to test checksum offloading, it would be great to find out how they perform on the checked-in version!
Now that BK is up, I'll run some netperf tests before/after that changeset and see what we get.
-Andrew
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Andrew Theurer

2005-05-23 15:47 UTC #6 lore raw

Quoted 2 lines · Bin Ren

It seems to break the interdomain ssh and nfs on my machine. Digging for reasons.

Are you using bridge or network model?

Quoted 36 lines

- Bin
Quoted 32 lines · Andrew Theurer
Quoted 16 lines
I've checked in a modified version of your patch that hopefully deals with propagating checksum information in both directions across a virtual bridge or router. I replaced your skb flags with two new ones -- proto_csum_blank and proto_csum_valid.
The former indicates that the protocol-level checksum needs filling in. This is not a problem for local processing, but the flag is picked up before sending to a physical interface and fixed up.
The latter indicates that the proto-level checksum has been validated since arrival at localhost (*or* that the packet originated from a domU on localhost). This flag survives crossing a bridge/router so we can trust it when deciding if checksum validation is required.
Quoted 6 lines
I'll push the patch to the bkbits repository just as soon as bkbits rematerialises. :-)
If you have any performance or stress tests that you were using to test checksum offloading, it would be great to find out how they perform on the checked-in version!
Now that BK is up, I'll run some netperf tests before/after that changeset and see what we get.
-Andrew
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Bin Ren

2005-05-23 15:56 UTC #7 lore raw

I'm using bridge and stock scripts. I start to doubt it's caused csum offloading, as I'm seeing some weird things. (1) it's possible to do interdomain iperf, which binds to ports > 1024 (2) ssh and nfs don't work. In both cases, dom0 is the server, dom1 is the client. tcpdump on dom0 doesn't show any incoming packets from dom1.

I'm recompiling everything again.

Cheers,
Bin

Quoted 43 lines · Andrew Theurer

Quoted 2 lines · Bin Ren
It seems to break the interdomain ssh and nfs on my machine. Digging for reasons.
Are you using bridge or network model?
Quoted 36 lines
- Bin
Quoted 32 lines · Andrew Theurer
Quoted 16 lines
I've checked in a modified version of your patch that hopefully deals with propagating checksum information in both directions across a virtual bridge or router. I replaced your skb flags with two new ones -- proto_csum_blank and proto_csum_valid.
The former indicates that the protocol-level checksum needs filling in. This is not a problem for local processing, but the flag is picked up before sending to a physical interface and fixed up.
The latter indicates that the proto-level checksum has been validated since arrival at localhost (*or* that the packet originated from a domU on localhost). This flag survives crossing a bridge/router so we can trust it when deciding if checksum validation is required.
Quoted 6 lines
I'll push the patch to the bkbits repository just as soon as bkbits rematerialises. :-)
If you have any performance or stress tests that you were using to test checksum offloading, it would be great to find out how they perform on the checked-in version!
Now that BK is up, I'll run some netperf tests before/after that changeset and see what we get.
-Andrew
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Bin Ren

2005-05-23 16:06 UTC #8 lore raw

Start from fresh again. The same weird symptoms.

- Bin

Quoted 56 lines · Bin Ren

I'm using bridge and stock scripts. I start to doubt it's caused csum offloading, as I'm seeing some weird things. (1) it's possible to do interdomain iperf, which binds to ports > 1024 (2) ssh and nfs don't work. In both cases, dom0 is the server, dom1 is the client. tcpdump on dom0 doesn't show any incoming packets from dom1.
I'm recompiling everything again.
Cheers,
Bin
Quoted 43 lines · Andrew Theurer
Quoted 2 lines · Bin Ren
It seems to break the interdomain ssh and nfs on my machine. Digging for reasons.
Are you using bridge or network model?
Quoted 36 lines
- Bin
Quoted 32 lines · Andrew Theurer
Quoted 16 lines
I've checked in a modified version of your patch that hopefully deals with propagating checksum information in both directions across a virtual bridge or router. I replaced your skb flags with two new ones -- proto_csum_blank and proto_csum_valid.
The former indicates that the protocol-level checksum needs filling in. This is not a problem for local processing, but the flag is picked up before sending to a physical interface and fixed up.
The latter indicates that the proto-level checksum has been validated since arrival at localhost (*or* that the packet originated from a domU on localhost). This flag survives crossing a bridge/router so we can trust it when deciding if checksum validation is required.
Quoted 6 lines
I'll push the patch to the bkbits repository just as soon as bkbits rematerialises. :-)
If you have any performance or stress tests that you were using to test checksum offloading, it would be great to find out how they perform on the checked-in version!
Now that BK is up, I'll run some netperf tests before/after that changeset and see what we get.
-Andrew
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Jon Mason

author

2005-05-23 16:16 UTC #9 lore raw

You can disable the checksum "offload" with ethtool (in domU). "ethtool -k eth0" will show whether it is enabled or not. "ethtool -K eth0 tx off" will disable it.
"ethtool -K eth0 tx on" will enable it.

I tested it throughly with bridging before I submitted the patch, so it should be working. I'll download the latest source and verify that it works on my test system.

Thanks for your help,
Jon

Quoted 63 lines · Bin Ren

Start from fresh again. The same weird symptoms.
- Bin
Quoted 6 lines · Bin Ren
I'm using bridge and stock scripts. I start to doubt it's caused csum offloading, as I'm seeing some weird things. (1) it's possible to do interdomain iperf, which binds to ports > 1024 (2) ssh and nfs don't work. In both cases, dom0 is the server, dom1 is the client. tcpdump on dom0 doesn't show any incoming packets from dom1.
Quoted 47 lines
I'm recompiling everything again.
Cheers,
Bin
Quoted 41 lines · Andrew Theurer
Quoted 2 lines · Bin Ren
It seems to break the interdomain ssh and nfs on my machine. Digging for reasons.
Are you using bridge or network model?
Quoted 35 lines
- Bin
Quoted 32 lines · Andrew Theurer
Quoted 16 lines
I've checked in a modified version of your patch that hopefully deals with propagating checksum information in both directions across a virtual bridge or router. I replaced your skb flags with two new ones -- proto_csum_blank and proto_csum_valid.
The former indicates that the protocol-level checksum needs filling in. This is not a problem for local processing, but the flag is picked up before sending to a physical interface and fixed up.
The latter indicates that the proto-level checksum has been validated since arrival at localhost (*or* that the packet originated from a domU on localhost). This flag survives crossing a bridge/router so we can trust it when deciding if checksum validation is required.
Quoted 6 lines
I'll push the patch to the bkbits repository just as soon as bkbits rematerialises. :-)
If you have any performance or stress tests that you were using to test checksum offloading, it would be great to find out how they perform on the checked-in version!
Now that BK is up, I'll run some netperf tests before/after that changeset and see what we get.
-Andrew
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Bin Ren

2005-05-23 16:36 UTC #10 lore raw

Keir has removed 'SET_ETHTOOL_OPS(dev, &network_ethtool_ops);' from your patch. The operations are not supported.

- Bin

Quoted 82 lines · Jon Mason

You can disable the checksum "offload" with ethtool (in domU). "ethtool -k eth0" will show whether it is enabled or not. "ethtool -K eth0 tx off" will disable it.
"ethtool -K eth0 tx on" will enable it.
I tested it throughly with bridging before I submitted the patch, so it should be working. I'll download the latest source and verify that it works on my test system.
Thanks for your help,
Jon
Quoted 59 lines · Bin Ren
Start from fresh again. The same weird symptoms.
- Bin
Quoted 6 lines · Bin Ren
I'm using bridge and stock scripts. I start to doubt it's caused csum offloading, as I'm seeing some weird things. (1) it's possible to do interdomain iperf, which binds to ports > 1024 (2) ssh and nfs don't work. In both cases, dom0 is the server, dom1 is the client. tcpdump on dom0 doesn't show any incoming packets from dom1.
Quoted 47 lines
I'm recompiling everything again.
Cheers,
Bin
Quoted 41 lines · Andrew Theurer
Quoted 2 lines · Bin Ren
It seems to break the interdomain ssh and nfs on my machine. Digging for reasons.
Are you using bridge or network model?
Quoted 35 lines
- Bin
Quoted 32 lines · Andrew Theurer
Quoted 16 lines
I've checked in a modified version of your patch that hopefully deals with propagating checksum information in both directions across a virtual bridge or router. I replaced your skb flags with two new ones -- proto_csum_blank and proto_csum_valid.
The former indicates that the protocol-level checksum needs filling in. This is not a problem for local processing, but the flag is picked up before sending to a physical interface and fixed up.
The latter indicates that the proto-level checksum has been validated since arrival at localhost (*or* that the packet originated from a domU on localhost). This flag survives crossing a bridge/router so we can trust it when deciding if checksum validation is required.
Quoted 6 lines
I'll push the patch to the bkbits repository just as soon as bkbits rematerialises. :-)
If you have any performance or stress tests that you were using to test checksum offloading, it would be great to find out how they perform on the checked-in version!
Now that BK is up, I'll run some netperf tests before/after that changeset and see what we get.
-Andrew
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Quoted 4 lines
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Keir Fraser

2005-05-23 17:54 UTC #11 lore raw

Quoted 2 lines · Bin Ren

Keir has removed 'SET_ETHTOOL_OPS(dev, &network_ethtool_ops);' from your patch. The operations are not supported.

Ah, I thought that was just testing infrastructure. I'll take a patch to add the ethtool ops back in.

Bin -- does your domain0 traffic get delivered via the bridge device or via the new vif0.0/veth0 that I added? If the former you might want to try updating your /etc/xen/scripts/network script. Although delivery via the bridge ought to work...

-- Keir

Bin Ren

2005-05-23 18:08 UTC #12 lore raw

It's via the new vif0.0/veth0. I did tcpdump on vif1.0 in dom0 and saw packets sent by dom0, but got dropped by the netfront on dom1.

Cheers,
Bin

Quoted 22 lines · Keir Fraser

Quoted 2 lines · Bin Ren
Keir has removed 'SET_ETHTOOL_OPS(dev, &network_ethtool_ops);' from your patch. The operations are not supported.
Ah, I thought that was just testing infrastructure. I'll take a patch to add the ethtool ops back in.
Bin -- does your domain0 traffic get delivered via the bridge device or via the new vif0.0/veth0 that I added? If the former you might want to try updating your /etc/xen/scripts/network script. Although delivery via the bridge ought to work...
-- Keir
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Jon Mason

author

2005-05-23 18:18 UTC #13 lore raw

thanks Bin,
I'll take a look at that.

Jon

Quoted 26 lines · Bin Ren

It's via the new vif0.0/veth0. I did tcpdump on vif1.0 in dom0 and saw packets sent by dom0, but got dropped by the netfront on dom1.
Cheers,
Bin
Quoted 19 lines · Keir Fraser
Quoted 2 lines · Bin Ren
Keir has removed 'SET_ETHTOOL_OPS(dev, &network_ethtool_ops);' from your patch. The operations are not supported.
Ah, I thought that was just testing infrastructure. I'll take a patch to add the ethtool ops back in.
Bin -- does your domain0 traffic get delivered via the bridge device or via the new vif0.0/veth0 that I added? If the former you might want to try updating your /etc/xen/scripts/network script. Although delivery via the bridge ought to work...
-- Keir
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Keir Fraser

2005-05-23 18:43 UTC #14 lore raw

I think I found the problem, and I've checked in a fix.

Bin: can you try dom0->domU networking with latest unstable tree? Hopefully your problem is fixed.

As further work on this, I think I chose a bad name for the 'proto_csum_valid' field because sometimes it is set for local packets that have had no csum poked into the packet at all. Something like 'proto_data_valid' might be better. And communicating this information between domains (i.e., that the csum field is blank, but the packet data is known good anyway) would be nice. Then domU can decide to add the checksum if it passes the packet off to a context that expects a valid checksum.

-- Keir

Quoted 11 lines · Jon Mason

thanks Bin,
I'll take a look at that.
Jon
Quoted 5 lines · Bin Ren
It's via the new vif0.0/veth0. I did tcpdump on vif1.0 in dom0 and saw packets sent by dom0, but got dropped by the netfront on dom1.
Cheers,
Bin

Bin Ren

2005-05-23 18:53 UTC #15 lore raw

Fantastic! It's working :-D

Thanks a great deal,
Bin

Quoted 37 lines · Keir Fraser

I think I found the problem, and I've checked in a fix.
Bin: can you try dom0->domU networking with latest unstable tree? Hopefully your problem is fixed.
As further work on this, I think I chose a bad name for the 'proto_csum_valid' field because sometimes it is set for local packets that have had no csum poked into the packet at all. Something like 'proto_data_valid' might be better. And communicating this information between domains (i.e., that the csum field is blank, but the packet data is known good anyway) would be nice. Then domU can decide to add the checksum if it passes the packet off to a context that expects a valid checksum.
-- Keir
Quoted 11 lines · Jon Mason
thanks Bin,
I'll take a look at that.
Jon
Quoted 5 lines · Bin Ren
It's via the new vif0.0/veth0. I did tcpdump on vif1.0 in dom0 and saw packets sent by dom0, but got dropped by the netfront on dom1.
Cheers,
Bin
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Bin Ren

2005-05-23 19:55 UTC #16 lore raw

In reply to Keir Fraser

I've added the support for ethtools. By turning on and off netfront checksum offloading, I'm getting the following throughput numbers, using iperf. Each test was run three times. CPU usages are quite similar in two cases ('top' output). Looks like checksum computation is not a major overhead in domU networking.

dom0/1/2 all have 128M memory. dom0 has e1000 tx checksum offloading turned on.

With Tx checksum on:

dom1->dom2: 300Mb/s (dom0 cpu maxed out by software interrupts) dom1->dom0: 459Mb/s (dom0 cpu 80% in SI, dom1 cpu 20% in SI) dom1->external: 439Mb/s (over 1Gb/s ethernet) (dom0 cpu 50% in SI, dom1 60% in SI)

With Tx checksum off:

dom1->dom2: 301Mb/s
dom1->dom0: 454Mb/s
dom1->externel: 437Mb/s (over 1Gb/s ethernet)

Quoted 22 lines · Keir Fraser

Quoted 2 lines · Bin Ren
Keir has removed 'SET_ETHTOOL_OPS(dev, &network_ethtool_ops);' from your patch. The operations are not supported.
Ah, I thought that was just testing infrastructure. I'll take a patch to add the ethtool ops back in.
Bin -- does your domain0 traffic get delivered via the bridge device or via the new vif0.0/veth0 that I added? If the former you might want to try updating your /etc/xen/scripts/network script. Although delivery via the bridge ought to work...
-- Keir
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Keir Fraser

2005-05-23 20:13 UTC #17 lore raw

Quoted 7 lines · Bin Ren

I've added the support for ethtools. By turning on and off netfront checksum offloading, I'm getting the following throughput numbers, using iperf. Each test was run three times. CPU usages are quite similar in two cases ('top' output). Looks like checksum computation is not a major overhead in domU networking.
dom0/1/2 all have 128M memory. dom0 has e1000 tx checksum offloading turned on.

What happens to CPU usage in dom1 when tx checksumming is disabled?

Overall though these are the kind of results I would expect. Linux usually does csumming at the same time as it has to do a copy anyway, and it ends up being limited by memory/L2-cache bandwidth, not the extra computation. But the offload extensions haven't cost much to implement and there are probably cases where it helps a little.

Maybe I'm being pessimistic though: Can you reproduce the rather more impressive speedups that you previously saw, Jon?

-- Keir

Jon Mason

author

2005-05-23 20:20 UTC #18 lore raw

Quoted 12 lines · Keir Fraser

Quoted 8 lines · Bin Ren
I've added the support for ethtools. By turning on and off netfront checksum offloading, I'm getting the following throughput numbers, using iperf. Each test was run three times. CPU usages are quite similar in two cases ('top' output). Looks like checksum computation is not a major overhead in domU networking.
dom0/1/2 all have 128M memory. dom0 has e1000 tx checksum offloading turned on.
What happens to CPU usage in dom1 when tx checksumming is disabled?

Quoted 8 lines

Overall though these are the kind of results I would expect. Linux usually does csumming at the same time as it has to do a copy anyway, and it ends up being limited by memory/L2-cache bandwidth, not the extra computation. But the offload extensions haven't cost much to implement and there are probably cases where it helps a little.
Maybe I'm being pessimistic though: Can you reproduce the rather more impressive speedups that you previously saw, Jon?

I would if I could. As I don't use BK, I'll have to wait for the nightly build to pull in your latest fix.

Thanks,
Jon

Bin Ren

2005-05-23 21:52 UTC #19 lore raw

In reply to Keir Fraser

Quoted 1 line · Keir Fraser

What happens to CPU usage in dom1 when tx checksumming is disabled?

dom1->dom0: 70.7% id, 0.0% wa, 1.7% hi, 15.0% si dom1->external: 20.0% id, 0.0% wa, 0.7% hi, 60.0% si dom1->dom2: 77.7% id, 0.0% wa, 1.0% hi, 9.3% si

Quoted 18 lines

Overall though these are the kind of results I would expect. Linux usually does csumming at the same time as it has to do a copy anyway, and it ends up being limited by memory/L2-cache bandwidth, not the extra computation. But the offload extensions haven't cost much to implement and there are probably cases where it helps a little.
Maybe I'm being pessimistic though: Can you reproduce the rather more impressive speedups that you previously saw, Jon?
-- Keir
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Jon Mason

author

2005-05-23 21:58 UTC #20 lore raw

In reply to Keir Fraser

Quoted 12 lines · Keir Fraser

Quoted 8 lines · Bin Ren
I've added the support for ethtools. By turning on and off netfront checksum offloading, I'm getting the following throughput numbers, using iperf. Each test was run three times. CPU usages are quite similar in two cases ('top' output). Looks like checksum computation is not a major overhead in domU networking.
dom0/1/2 all have 128M memory. dom0 has e1000 tx checksum offloading turned on.
What happens to CPU usage in dom1 when tx checksumming is disabled?

Quoted 8 lines

Overall though these are the kind of results I would expect. Linux usually does csumming at the same time as it has to do a copy anyway, and it ends up being limited by memory/L2-cache bandwidth, not the extra computation. But the offload extensions haven't cost much to implement and there are probably cases where it helps a little.
Maybe I'm being pessimistic though: Can you reproduce the rather more impressive speedups that you previously saw, Jon?

Alright, I broke down and got a BK puller.

I get the following domU->dom0 throughput on my system (using netperf3 TCP_STREAM testcase):
tx on ~1580Mbps
tx off ~1230Mbps

with my previous patch (on Friday's build), I was seeing the following:
with patch ~1610Mbps
no patch ~1100Mbps

The slight difference between the two might be caused by the changes that were incorporated in xen between those dates. If you think it is worth the time, I can back port the latest patch to Friday's build to see if that makes a difference.

Thanks,
Jon

Bin Ren

2005-05-23 22:05 UTC #21 lore raw

Quoted 8 lines · Jon Mason

I get the following domU->dom0 throughput on my system (using netperf3 TCP_STREAM testcase):
tx on ~1580Mbps
tx off ~1230Mbps
with my previous patch (on Friday's build), I was seeing the following:
with patch ~1610Mbps
no patch ~1100Mbps

I suppose you are running dom0 and dom1 on different CPUs. Is it possible for you to pin them to the same CPU and get the numbers again? It'll show how much overhead context switches and CPU share halved could incur.

Thanks a lot,
Bin

Quoted 14 lines

The slight difference between the two might be caused by the changes that were incorporated in xen between those dates. If you think it is worth the time, I can back port the latest patch to Friday's build to see if that makes a difference.
Thanks,
Jon
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Jon Mason

author

2005-05-23 22:41 UTC #22 lore raw

Quoted 11 lines · Bin Ren

Quoted 8 lines · Jon Mason
I get the following domU->dom0 throughput on my system (using netperf3 TCP_STREAM testcase):
tx on ~1580Mbps
tx off ~1230Mbps
with my previous patch (on Friday's build), I was seeing the following:
with patch ~1610Mbps
no patch ~1100Mbps
I suppose you are running dom0 and dom1 on different CPUs. Is it

Yes, I am.

Quoted 3 lines

possible for you to pin them to the same CPU and get the numbers again? It'll show how much overhead context switches and CPU share halved could incur.

I pinned them to the same CPU and got the following:
tx on ~1480Mbps
tx off ~1330Mbps

Quoted 13 lines

Quoted 13 lines
The slight difference between the two might be caused by the changes that were incorporated in xen between those dates. If you think it is worth the time, I can back port the latest patch to Friday's build to see if that makes a difference.
Thanks,
Jon
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Nivedita Singhvi

2005-05-23 21:12 UTC #23 lore raw

In reply to Bin Ren

Quoted 7 lines · Bin Ren

I've added the support for ethtools. By turning on and off netfront checksum offloading, I'm getting the following throughput numbers, using iperf. Each test was run three times. CPU usages are quite similar in two cases ('top' output). Looks like checksum computation is not a major overhead in domU networking.
dom0/1/2 all have 128M memory. dom0 has e1000 tx checksum offloading turned on.

Yeah, if you want to do anything network intensive, 128MB is just not enough - you really need more memory in your system.

Quoted 7 lines

With Tx checksum on:
dom1->dom2: 300Mb/s (dom0 cpu maxed out by software interrupts) dom1->dom0: 459Mb/s (dom0 cpu 80% in SI, dom1 cpu 20% in SI) dom1->external: 439Mb/s (over 1Gb/s ethernet) (dom0 cpu 50% in SI, dom1 60% in SI)

Quoted 5 lines

With Tx checksum off:
dom1->dom2: 301Mb/s
dom1->dom0: 454Mb/s
dom1->externel: 437Mb/s (over 1Gb/s ethernet)

iperf is a directional send test, correct?
i.e. is dom1 -> dom0 perf the same as dom0 -> dom1 for you?

thanks,
Nivedita

Bin Ren

2005-05-23 21:48 UTC #24 lore raw

Quoted 11 lines · Nivedita Singhvi

Quoted 7 lines · Bin Ren
I've added the support for ethtools. By turning on and off netfront checksum offloading, I'm getting the following throughput numbers, using iperf. Each test was run three times. CPU usages are quite similar in two cases ('top' output). Looks like checksum computation is not a major overhead in domU networking.
dom0/1/2 all have 128M memory. dom0 has e1000 tx checksum offloading turned on.
Yeah, if you want to do anything network intensive, 128MB is just not enough - you really need more memory in your system.

I've given all the domains 256M memory and switched to netperf TCP_STREAM (netperf -H server). almost no change. Details:

dom1->external: 420Mbps
dom1->dom0: 437Mbps
dom0->dom1: 200Mbps (!!!)
dom1->dom2: 327Mbps

Quoted 10 lines

Quoted 10 lines
With Tx checksum on:
dom1->dom2: 300Mb/s (dom0 cpu maxed out by software interrupts) dom1->dom0: 459Mb/s (dom0 cpu 80% in SI, dom1 cpu 20% in SI) dom1->external: 439Mb/s (over 1Gb/s ethernet) (dom0 cpu 50% in SI, dom1 60% in SI)
With Tx checksum off:

Quoted 7 lines

Quoted 3 lines
dom1->dom2: 301Mb/s
dom1->dom0: 454Mb/s
dom1->externel: 437Mb/s (over 1Gb/s ethernet)
iperf is a directional send test, correct?
i.e. is dom1 -> dom0 perf the same as dom0 -> dom1 for you?

Please see above.

Rolf Neugebauer

2005-05-23 23:55 UTC #25 lore raw

These results are pretty bad.

What do you get for dom0->external? That definitely should be close or equal to native.

Have you tweaked /proc/sys/net/core/rmem_max? Is the socket buffer set to some large value? Are you transmitting/receiving enough data?

I don't know netperf but for ttcp I would normally do:

echo 1048576 > /proc/sys/net/core/rmem_max ttcp -b 65536 (or similar) ...
And then transmit a few gigabytes

What's the interrupt rate etc.

Rolf

Quoted 46 lines · Bin Ren

Quoted 7 lines · Nivedita Singhvi
Quoted 6 lines · Bin Ren
I've added the support for ethtools. By turning on and off netfront checksum offloading, I'm getting the following throughput numbers, using iperf. Each test was run three times. CPU usages are quite similar in two cases ('top' output). Looks like checksum computation is not a major overhead in domU networking.
Quoted 5 lines
Quoted 2 lines
dom0/1/2 all have 128M memory. dom0 has e1000 tx checksum offloading turned on.
Yeah, if you want to do anything network intensive, 128MB is just not enough - you really need more memory in your system.
I've given all the domains 256M memory and switched to netperf TCP_STREAM (netperf -H server). almost no change. Details:
dom1->external: 420Mbps
dom1->dom0: 437Mbps
dom0->dom1: 200Mbps (!!!)
dom1->dom2: 327Mbps
Quoted 10 lines
Quoted 10 lines
With Tx checksum on:
dom1->dom2: 300Mb/s (dom0 cpu maxed out by software interrupts) dom1->dom0: 459Mb/s (dom0 cpu 80% in SI, dom1 cpu 20% in SI) dom1->external: 439Mb/s (over 1Gb/s ethernet) (dom0 cpu 50% in SI, dom1 60% in SI)
With Tx checksum off:
Quoted 7 lines
Quoted 3 lines
dom1->dom2: 301Mb/s
dom1->dom0: 454Mb/s
dom1->externel: 437Mb/s (over 1Gb/s ethernet)
iperf is a directional send test, correct?
i.e. is dom1 -> dom0 perf the same as dom0 -> dom1 for you?
Please see above.
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel

Bin Ren

2005-05-24 00:38 UTC #26 lore raw

Quoted 4 lines · Rolf Neugebauer

These results are pretty bad.
What do you get for dom0->external? That definitely should be close or equal to native.

with default BVT, dom->external gets 643Mbps. native gets 744Mbps.

Quoted 1 line

Have you tweaked /proc/sys/net/core/rmem_max?

No. I once did Linux tcp tuning on native linux and increased the throughput to around 810Mbps. But it's not very stable and occasionally produced weird behaviors so I turned off tuning on both server and client.

Quoted 1 line

Is the socket buffer set to some large value?

Both sender and receiver buffers are 32K.

Quoted 1 line

Are you transmitting/receiving enough data?

Each tests last 50 seconds, transmitting around 3g data.

Quoted 8 lines

I don't know netperf but for ttcp I would normally do:
echo 1048576 > /proc/sys/net/core/rmem_max
ttcp -b 65536 (or similar) ...
And then transmit a few gigabytes
What's the interrupt rate etc.

Haven't noticed yet. I'll get you the number tomorrow.

What currently I'm really really obssessed is (1) dom1->external with default BVT gives only ~400Mbps (2) dom1->external with my EEVDF scheduler (everything else is exactly the same) gives 610Mbps, very close to dom0->external. With scheduler latency histograms, it seems to be caused by *far too frequent* context switches in BVT. I'm still digging.

Thanks a lot,
Bin

Quoted 54 lines

Rolf
Quoted 46 lines · Bin Ren
Quoted 7 lines · Nivedita Singhvi
Quoted 6 lines · Bin Ren
I've added the support for ethtools. By turning on and off netfront checksum offloading, I'm getting the following throughput numbers, using iperf. Each test was run three times. CPU usages are quite similar in two cases ('top' output). Looks like checksum computation is not a major overhead in domU networking.
Quoted 5 lines
Quoted 2 lines
dom0/1/2 all have 128M memory. dom0 has e1000 tx checksum offloading turned on.
Yeah, if you want to do anything network intensive, 128MB is just not enough - you really need more memory in your system.
I've given all the domains 256M memory and switched to netperf TCP_STREAM (netperf -H server). almost no change. Details:
dom1->external: 420Mbps
dom1->dom0: 437Mbps
dom0->dom1: 200Mbps (!!!)
dom1->dom2: 327Mbps
Quoted 10 lines
Quoted 10 lines
With Tx checksum on:
dom1->dom2: 300Mb/s (dom0 cpu maxed out by software interrupts) dom1->dom0: 459Mb/s (dom0 cpu 80% in SI, dom1 cpu 20% in SI) dom1->external: 439Mb/s (over 1Gb/s ethernet) (dom0 cpu 50% in SI, dom1 60% in SI)
With Tx checksum off:
Quoted 7 lines
Quoted 3 lines
dom1->dom2: 301Mb/s
dom1->dom0: 454Mb/s
dom1->externel: 437Mb/s (over 1Gb/s ethernet)
iperf is a directional send test, correct?
i.e. is dom1 -> dom0 perf the same as dom0 -> dom1 for you?
Please see above.
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel