Does the data for a large send offload have to occupy more than one page? In tuning the windows drivers, if I set the minimum mss multiple before considering offload (a windows variable) to 2, then I seem to get hangs. If I set it to 4 then everything appears to be okay. If the mss is 1460 (normal for Ethernet), then 2 * 1460 = 2920, which will often fit into one page, in which case the ring looks like: 0: tx_request - flags |= NETTXF_extra_info 1: extra_info If the 2920 bytes were on more than one page, then the ring would look like: 0: tx_request - flags |= NETTXF_extra_info | NETTXF_more_data 1: extra_info 2: tx_request - no change to flags The behaviour I''m seeing is that I''ll get a bunch of packets working just fine, then it will pause for a bit, and I''m wondering if I could be getting a bunch of the latter above case, and then one of the former which causes the hang. I haven''t yet put debug statements in to find out which of the above is the packet before the hang... I''ll do that tomorrow. Any suggestions? Thanks James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sat, Mar 08, 2008 at 11:01:36PM +1100, James Harper wrote:> Does the data for a large send offload have to occupy more than one > page? In tuning the windows drivers, if I set the minimum mss multiple > before considering offload (a windows variable) to 2, then I seem to get > hangs. If I set it to 4 then everything appears to be okay. > > If the mss is 1460 (normal for Ethernet), then 2 * 1460 = 2920, which > will often fit into one page, in which case the ring looks like: > > 0: tx_request - flags |= NETTXF_extra_info > 1: extra_info > > If the 2920 bytes were on more than one page, then the ring would look > like: > > 0: tx_request - flags |= NETTXF_extra_info | NETTXF_more_data > 1: extra_info > 2: tx_request - no change to flags > > The behaviour I''m seeing is that I''ll get a bunch of packets working > just fine, then it will pause for a bit, and I''m wondering if I could be > getting a bunch of the latter above case, and then one of the former > which causes the hang. I haven''t yet put debug statements in to find out > which of the above is the packet before the hang... I''ll do that > tomorrow. > > Any suggestions? >Hmm.. might be a stupid suggestion/question, but have you checked the unmodified (pv-on-hvm) drivers for Linux and how they do that? -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> > Hmm.. might be a stupid suggestion/question, but have you checked the > unmodified (pv-on-hvm) drivers for Linux and how they do that? >The stupidity was on my part. I was setting feature-gso-tcpv4 to 0, not 1! James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Seemingly Similar Threads
- R CMD Rdconv drops sections: arguments, seealso, examples (PR#9649)
- Xen Windows Clients - BSOD with Application Firewall Installs
- cannot connect without user/pass on Windows 10
- What's this 135/UDP traffic?
- Transport endpoint is not connected while mounting....