----- Original Message ----- From: "Tim Durack" <tdurack@xxxxxxxxx> >I have had similar issues with a Broadcom 5700 based NIC. > Both tg3 and bcm5700 driver exhibits checksum problems. > > The Xen guys have not been able to resolve this, perhaps because there > haven't been enough users experiencing the problem. I also have a Tyan server with which I did some early experimenting with. It has two tg3 based NIC's (it's the only machine I have with tg3 NIC's). I don't understand why, but I seem to have a very similar setup working on it. I'm not convinced it is necessarily a xen issue. Can you point me towards a thread in the xen lists where this has been discussed? (I have searched, but don't think I found a similar problem, and I have posted in the xen lists). Is there a xen bugzilla open for this issue? > Using a bridged setup instead of routed also seems to avoid this > problem. As I understand it I am using a bridged setup. Traffic passes through the xen frontend/backend driver (eth0/vifN.0), through the bridge, and then through the VLAN interface and the ethernet driver. If I remove the VLAN interface (and use untagged frames on the wire) it starts working. I don't understand how the various drivers signal checksum offloading. How far back through the chain of drivers will get the benefit of the checksum offload? Is adding 'just one more' driver (the VLAN driver) the problem? > I have also been experiencing MTU issues. Connections will stall unless > I set mtu <1000. I don't know why this is. Again I have just worked > around it. I will try setting the MTU less than 1000. I don't understand how that would help, given the only traffic I've got is ARP's and domain lookups. All these packets are less than 100 bytes in size. > This might not help you with your problem, but it does highlight that > Xen (as much as I love it) seems to have some annoying network > stack/driver bugs still. No but it gives me the impression that it might not just be a local configuration error. Greg :-)
