On March 3, 2007 06:40:12 pm John Heffner wrote: > David Miller wrote: > > From: John Heffner <[EMAIL PROTECTED]> > > Date: Fri, 02 Mar 2007 16:16:39 -0500 > > > >> Please don't apply the patch I sent. I've been thinking about this a > >> bit harder, and it may not fix this particular problem. (Hard to say > >> without knowing exactly what it is.) As the comment above > >> __tcp_select_window() states, we do not do full receive-side SWS > >> avoidance because of header prediction. > >> > >> Alex, you're right I missed that special zero-window case. I'm still > >> not quite sure I'm completely happy with this patch. I'd like to think > >> about this a little bit harder... > > > > Ok > > Alright, I've thought about it a bit more, and I think the patch I sent > should work. Alex, any opinion? Any way you can test this out?
Here are the values from live kernel (obtained with 'crash') when the host was in SWS state: full_space=708 full_space/2=354 free_space=393 window=76 In this case the test from my original fix, (window < full_space/2), succeeds. But John's test free_space > window + full_space/2 393 430 does not. So I suspect that the new fix will not always work. From tcpdump traces we can see that both hosts exchange with 76-byte packets for a long time. From customer's application log we see that it continues to read 76-byte chunks per each read() call - even though more than that is available in the receive buffer. Technically it's OK for read() to return even after reading one byte, so if sk->receive_queue contains multiple 76-byte skbuffs we may return after processing just one skbuff (but we we don't understand the details of why this happens on customer's system). Are there any particular reasons why you want to postpone window update until free_space becomes > window + full_space/2 and not as soon as free_space > full_space/2? As the only real-life occurance of SWS shows free_space oscillating slightly above full_space/2, I created the fix specifically to match this phenomena as seen on customer's host. We reach the modified section only when (free_space > full_space/2) so it should be OK to update the window at this point if mss==full_space. So yes, we can test John's fix on customer's host but I doubt it will work for the reasons mentioned above, in brief: 'window = free_space' instead of 'window=full_space/2' is OK, but the test 'free_space > window + full_space/2' is not for the specific pattern customer sees on his hosts. Thanks, Alex -- ------------------------------------------------------------------ Alexandre Sidorenko email: [EMAIL PROTECTED] Global Solutions Engineering: Unix Networking Hewlett-Packard (Canada) ------------------------------------------------------------------ - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
