[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-users] Slow windows network with gplpv driver.
> > > Server 2003 sp2 (or was it sp1?) removed the TPR instructions from the > > kernel and did things a slightly different way so it's not necessary > > there. > > > > Ah, okay. > > > Slow performance to where? DomU<->Dom0, DomU<->DomU, or DomU<->physical > > network, or all of them? > > > > All of the above - it actually ends up generating invalid checksums on > the packets. > The point of the offloading in DomU is that no checksum generation is necessary, so the checksums will always be invalid while the packets exist on the bridge. If the packet is sent to another DomU that supports checksum offload then Dom0 will leave the checksum invalid and pass a flag with the packet to say that the packet is checked and so looking at the checksum is unnecessary. If the packet is sent to a DomU that doesn't support offload then Dom0 will just calculate the checksum. If the packet hits a physical network adapter then the hardware will calculate the checksum or if the hardware doesn't support it then Dom0 will calculate it. That's the way it's supposed to work. I have seen problem where: . The packet is routed onto a GRE tunnel. This was a while back (~2.6.18 I think) and erratic... it would work fine for a week then suddenly start spitting out bad packets onto the GRE tunnel. . The packet is bridged onto a VLAN on a physical network adapter. Some network adapters support checksum offload but only for the untagged vlan 1. Linux seems to not handle this correctly for some (all?) such adapters so the checksum is never calculated. Same for large send offload. Again, I only saw this on older kernels but in that case the offload has not been turned on again for newer kernels as the performance isn't required (routing out to WAN connections etc). And I'm sure there are more cases where it is a problem. But when it's all working properly, seeing packets on your bridge with invalid checksums is expected. James _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |