On Fri, 7 Dec 2007, Ilpo Järvinen wrote: > 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?
Hmm... this could be solved though by postponing the fragmentation of a partially sacked skb when the first sack block can (is likely) to still grow and remove the need for fragmentation. Has some implications to packet processing, increases burstiness a bit & tcp_max_burst kicks in too easily. -- i.
