James Harper
2008-Mar-11 10:13 UTC
[Xen-devel] continued problems with large send offload in windows
I''m still trying to figure out what is going wrong with large send support in windows. I thought I was doing all the right things but obviously something is going wrong... Windows sends my driver a packet of length 4434 with an mss of 1460, comprising of the following sg items (pages): Page 0 - addr 19efc312, length 54 Page 1 - addr 02776000, length 4096 Page 2 - addr 02777000, length 284 I put this onto the tx ring as follows: Slot 0 - pfn 19efc, offset 312, length 4434, NETTXF_extra_info|NETTXF_csum_blank|NETTXF_data_validated|NETTXF_more_da ta Slot 1 - extra info - mss = 1460 Slot 2 - pfn 02776000, offset 0, length 4096, NETTXF_more_data Slot 3 - pfn 02777000, offset 0, length 284 A tcpdump on Dom0 receives this as the following: (connection setup stuff - MSS = 1460) Packet 0 - TCP Seq = 1, Length = 24 Packet 1 - TCP Seq = 25, Length = 4380 Packet 2 - TCP Seq = 1485, Length = 2920 Packet 3 - TCP Seq = 2945, Length = 1460 Dom0 meanwhile is sending acks and getting them all wrong... obviously things have fallen to pieces badly somewhere. I''ve had a look at the equivalent Linux code, frontend and back, but I don''t know enough about skb''s to tell if there is anything special happening to packet/page lengths with GSO... maybe I''m supposed to do something different? Can anyone offer any suggestions as to where I''m going wrong? Maybe there is a fundamental difference between how windows formats a packet for large send offload and how linux formats it? Thanks James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
James Harper
2008-Mar-11 13:18 UTC
RE: [Xen-devel] continued problems with large send offload in windows
> > I''m still trying to figure out what is going wrong with large send > support in windows. I thought I was doing all the right things but > obviously something is going wrong... > > Windows sends my driver a packet of length 4434 with an mss of 1460, > comprising of the following sg items (pages): > Page 0 - addr 19efc312, length 54 > Page 1 - addr 02776000, length 4096 > Page 2 - addr 02777000, length 284 > > I put this onto the tx ring as follows: > Slot 0 - pfn 19efc, offset 312, length 4434, >NETTXF_extra_info|NETTXF_csum_blank|NETTXF_data_validated|NETTXF_more_da> ta > Slot 1 - extra info - mss = 1460 > Slot 2 - pfn 02776000, offset 0, length 4096, NETTXF_more_data > Slot 3 - pfn 02777000, offset 0, length 284 > > A tcpdump on Dom0 receives this as the following: > (connection setup stuff - MSS = 1460) > Packet 0 - TCP Seq = 1, Length = 24 > Packet 1 - TCP Seq = 25, Length = 4380 > Packet 2 - TCP Seq = 1485, Length = 2920 > Packet 3 - TCP Seq = 2945, Length = 1460 > > Dom0 meanwhile is sending acks and getting them all wrong... obviously > things have fallen to pieces badly somewhere. >I think I''ve figured it out - when Windows gives me a packet to send, one of the OOB data fields tells me the MSS for a large send offload operation. After sending, I''m supposed to put the actual number of bytes I sent back in that field and I wasn''t doing it. So ''Packet 2'' above was actually another packet from Windows with the unsent (according to what I told Windows) data, not Dom0 making something up because I''d given it some wrong information... James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel