Re: [Xen-devel] State of Xen and bonding

[Greg Brackley <lists-xen-devel@xxxxxxxxxxxxxxxxxxxx>]

----- Original Message ----- 
> From: <Peter.Weiss@xxxxxxxxx>
> I'm trying to setup Xen on a machine with 2 physical network devices using
> linux bonding without success.
I believe it is possible to use bonding with Xen.  I have one machine 
running successfully with 802.3ad bonding.
I have had a few problems with the networking, but I have overcome most of 
them.  I was trying to use the bonding support in conjunction with VLAN 
support. I still have concerns that there are some outstanding issues with 
checksum offload support in the Xen network drivers.
To get the xenU networking operating I found I needed to disable checksum 
offload support (ethtool -k eth0 tx off).  There doesn't appear to be any 
such ethtool support in the xen0 loopback driver.  I also dug around a 
little in the kernel code to look at the checksum offload options[1][2], and 
was unclear as to why a loopback style device like the xen loopback driver 
was declaring that it was capable of TCP/UDP IPv4 checksum offload.  It 
might explain why I could get ICMP working but not UDP/TCP (Note sure how/if 
this relates to similar IPsec issues).  I would be very keen to get 
clarification on this (please?).
I think there might also be some interaction with the NIC driver. My tg3 
based machine works 'out of the box', whereas the e1000 solution requires 
the checksum offload disabled in the Xen driver. I was also using a non-GPL 
sk98lin based sk-9e22 card which was having problems, but I plan to use the 
newer sky2 driver when I get time.
You didn't mention what problems you were having? Whether it worked without 
xen, etc. What does /proc/net/bonding/* say?
I have been disabling the xen network script (and not doing the interface 
renaming etc), and using the FC4 init scripts to bring up my xen0 
networking. I needed to tweak the xen0 hotplug. Other than the problems 
discussed above I have managed to get the networking going.  I would like to 
resolve the checksim offload, but have had time to look into it.
Greg :-)



[1] linux/netdevice.h

       /* Net device features */
       unsigned long           features;
#define NETIF_F_SG              1       /* Scatter/gather IO. */
#define NETIF_F_IP_CSUM         2       /* Can checksum only TCP/UDP over 
IPv4. */
#define NETIF_F_NO_CSUM         4       /* Does not require checksum. F.e. 
loopack. */
#define NETIF_F_HW_CSUM         8       /* Can checksum all the packets. */
#define NETIF_F_HIGHDMA         32      /* Can DMA to high memory. */
#define NETIF_F_FRAGLIST        64      /* Scatter/gather IO. */
#define NETIF_F_HW_VLAN_TX      128     /* Transmit VLAN hw acceleration */
#define NETIF_F_HW_VLAN_RX      256     /* Receive VLAN hw acceleration */
#define NETIF_F_HW_VLAN_FILTER  512     /* Receive filtering on VLAN */
#define NETIF_F_VLAN_CHALLENGED 1024    /* Device cannot handle VLAN packets 
*/
#define NETIF_F_TSO             2048    /* Can offload TCP/IP segmentation 
*/
#define NETIF_F_LLTX            4096    /* LockLess TX */


[2] linux/skbuff.h

#define CHECKSUM_NONE 0
#define CHECKSUM_HW 1
#define CHECKSUM_UNNECESSARY 2

/* A. Checksumming of received packets by device.
*
*      NONE: device failed to checksum this packet.
*              skb->csum is undefined.
*
*      UNNECESSARY: device parsed packet and wouldbe verified checksum.
*              skb->csum is undefined.
*            It is bad option, but, unfortunately, many of vendors do this.
*            Apparently with secret goal to sell you new device, when you
*            will add new protocol to your host. F.e. IPv6. 8)
*
*      HW: the most generic way. Device supplied checksum of _all_
*          the packet as seen by netif_rx in skb->csum.
*          NOTE: Even if device supports only some protocols, but
*          is able to produce some skb->csum, it MUST use HW,
*          not UNNECESSARY.
*
* B. Checksumming on output.
*
*      NONE: skb is checksummed by protocol or csum is not required.
*
*      HW: device is required to csum packet as seen by hard_start_xmit
*      from skb->h.raw to the end and to record the checksum
*      at skb->h.raw+skb->csum.
*
*      Device must show its capabilities in dev->features, set
*      at device setup time.
*      NETIF_F_HW_CSUM - it is clever device, it is able to checksum
*                        everything.
*      NETIF_F_NO_CSUM - loopback or reliable single hop media.
*      NETIF_F_IP_CSUM - device is dumb. It is able to csum only
*                        TCP/UDP over IPv4. Sigh. Vendors like this
*                        way by an unknown reason. Though, see comment 
above
*                        about CHECKSUM_UNNECESSARY. 8)
*
*      Any questions? No questions, good.              --ANK
*/

[3] Usages of checksum flags in the Xen code

netback/interface.c:    dev->features        = NETIF_F_NO_CSUM;
netback/loopback.c:     dev1->features |= NETIF_F_NO_CSUM;
netback/loopback.c:     dev2->features |= NETIF_F_IP_CSUM;
netfront/netfront.c:    netdev->features        = NETIF_F_IP_CSUM;


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel