Hi,
I had another look at our TSO issues. A few things:
1. tcpdump doesnt report local TSO packets, it simply prints bad-len. I
think this is because the e1000 driver is zeroing out the IP header
length in e1000_tso:
skb->nh.iph->tot_len = 0;
Does the card require this for TSO to operate? Ive worked around it in
tcpdump for the time being.
2. TSO never gets reenabled after a retransmit. With long lasting
connections this hurts, we get one retransmit and its all over. Not so
important for a web server, but we have big CIFS (windows networking)
servers where connections can last days. When its working TSO gives us a
nice bump here.
3. Im getting e1000 rx fifo overruns on the receive side. Doubling the
flow control watermarks seems to help. Due to bug 2, whenever we get an
rx fifo overrun TSO gets disabled on that connection.
4. Im seeing some strange stuff during connection startup.
I have bumped win_divisor to 2 (so TSO gets enabled in a reasonable
time). There are nice big send and receive socket buffers (512k).
Id expect TSO to cut in fairly quickly. The both direction test is as Id
expect. It takes a few packets for our slow start window to grow and
then we start sending TSO packets (evidenced by the first bad-len)
packet.
Now if we do a single direction test it takes forever for TSO to kick
in. At the moment Im not sure why this is happening, tcp_current_mss
seems to grow correctly in both cases. Is there somewhere else we are
capping TSO packets?
Finally, I set divisor to 1 and you can see for both tests TSO cuts
right in. I cant explain the big difference between divisor = 1 and
divisor = 2 yet, any thoughts?
Anton
divisor_2_both
Description: Text document
divisor_2_single.wGmSv6
Description: Text document
divisor_1_both
Description: Text document
divisor_1_single
Description: Text document
|