Re: [Xen-devel] checksum errors with large send

[James Harper <james.harper@xxxxxxxxxxxxxxxx>]

> 
> A user has reported a problem with GPLPV with large packets, having looked
> at a tcpdump I can see that a large packet (10k) is being sent, but the
> resulting packets received at the other end have incorrect TCP checksums.
> The checksums of the received packets are all different to each other, so
> something is making an attempt to calculate a checksum, which I assume is
> the hardware. In theory, the windows
> 
> It all works fine on my systems - I get line speed on gigabit hardware with no
> bad checksums, so I can't think what is going on, unless the way windows
> calculates the pseudoheader  checksum isn't compatible with what Linux
> wants...
> 

I just noticed the checksums for the generated packets are all out by exactly 
10240, which is the total IP payload size (TCP header + TCP payload):

Total frame size: 10274 bytes
Ethernet header length: 14 bytes
IP header length:  20 bytes
TCP header length: 20 bytes
TCP data length: 10220 bytes

The MS literature on the "TCP Length" component for the psuedoheader for an LSO 
packet says:
(http://msdn.microsoft.com/en-us/library/windows/hardware/ff568840%28v=vs.85%29.aspx)
Note that RFC 793 stipulates that the pseudo-header checksum is calculated over 
the Source IP Address, Destination IP Address, Protocol, and TCP Length. (The 
TCP Length is the length of the TCP header plus the length of the TCP payload. 
The TCP Length does not include the length of the pseudo-header.) However, 
because the underlying miniport driver and NIC generate TCP segments from the 
large packet that is passed down by the TCP/IP transport, the transport does 
not know the size of the TCP payload for each TCP segment and therefore cannot 
include the TCP Length in the pseudo-header. Instead, as described below, the 
NIC extends the pseudo-header checksum that was supplied by the TCP/IP 
transport to cover the TCP Length of each generated TCP segment.

I don't know where to go next though.

Thanks

James

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel