On Fri, 7 Dec 2007, David Miller wrote: > From: "Ilpo_Järvinen" <[EMAIL PROTECTED]> > Date: Fri, 7 Dec 2007 13:05:46 +0200 (EET) > > > I guess if you get a large cumulative ACK, the amount of processing is > > still overwhelming (added DaveM if he has some idea how to combat it). > > > > Even a simple scenario (this isn't anything fancy at all, will occur all > > the time): Just one loss => rest skbs grow one by one into a single > > very large SACK block (and we do that efficiently for sure) => then the > > fast retransmit gets delivered and a cumulative ACK for whole orig_window > > arrives => clean_rtx_queue has to do a lot of processing. In this case we > > could optimize RB-tree cleanup away (by just blanking it all) but still > > getting rid of all those skbs is going to take a larger moment than I'd > > like to see. > > > > That tree blanking could be extended to cover anything which ACK more than > > half of the tree by just replacing the root (and dealing with potential > > recolorization of the root). > > Yes, it's the classic problem. But it ought to be at least > partially masked when TSO is in use, because we'll only process > a handful of SKBs. The more effectively TSO batches, the > less work clean_rtx_queue() will do.
No, that's not what is going to happen, TSO won't help at all because one-by-one SACKs will fragment every single one of them (see tcp_match_skb_to_sack) :-(. ...So we're back in non-TSO case, or am I missing something? > Web100 just provides statistics and other kinds of connection data > to userspace, all the actual algorithm etc. modifications have been > merged upstream and yanked out of the web100 patch. I was looking > at it the other night and it's frankly totally uninteresting these > days :-) ...Thanks, I'll keep that in my mind when looking... :-) -- i.
