RE: [Xen-users] Slow windows network with gplpv driver.

["James Harper" <james.harper@xxxxxxxxxxxxxxxx>]

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