| |
|
 |
|
 |
|
|
|
| |
|
|
xen-users
RE: [Xen-users] Slow windows network with gplpv driver.
> >
>
> 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.
Right, understood, but I tend to see bad checksums on packets when they
reach the destination (or are on the wire, via a Network TAP), and not
just on the local bridge.
>
> 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).
This definitely describes one of my scenarios - on my production systems
(SLES10 and SLES11) I frequently tag VLANs on a single physical
interface. However, I also see the problem on some of my Desktop Xen
systems where I'm running Xen + openSuSE 11.3 + Windows XP VM, with a
single bridge that does not use VLANs.
I'll have to do some more checking and make sure I work through all of
the scenarios...
-Nick
--------
This e-mail may contain confidential and privileged material for the sole use
of the intended recipient. If this email is not intended for you, or you are
not responsible for the delivery of this message to the intended recipient,
please note that this message may contain SEAKR Engineering (SEAKR)
Privileged/Proprietary Information. In such a case, you are strictly
prohibited from downloading, photocopying, distributing or otherwise using this
message, its contents or attachments in any way. If you have received this
message in error, please notify us immediately by replying to this e-mail and
delete the message from your mailbox. Information contained in this message
that does not relate to the business of SEAKR is neither endorsed by nor
attributable to SEAKR.
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
|
|
| |
|
Home