[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

----- 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_HW 1

/* 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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.