David S. Miller wrote: > From: "Wael Noureddine" <[EMAIL PROTECTED]> > Date: Sun, 21 Aug 2005 00:54:51 -0700 > > >>>You could also tweak the LRO timeout in a similar fashion based upon >>>traffic patterns as well. In fact, extremely sophisticated things can >>>be done here to deal with the LRO timing as seen on WAN vs. LAN >>>streams. >> >>The accurate statement is "extremely complicated things need to be done here >>to deal with the LRO timing as seen on WAN vs. LAN streams". Not to mention >>dealing with retransmissions and the dynamics of congestion control. > > > LRO will just stop accumulating when out-of-sequence data arrives. > Nothing complicated at all. > > And that's _EXACTLY_ what we want to happen. We want Linux's TCP loss > response algorithms to take care of things, which have been > extensively tuned over many many years and gets several orders of > magnitude more testing and exposure than any customized stack you guys > put onto a network card.
Actually, at high speeds SACK processing becomes a huge bottleneck by itself. If we could have some help from the hardware with pruning some of the trivial cases it would help, I guess. One thing I can think of and which I implemented in software is a SACK cache feature where at high speeds kicks in and starts processing SACKs every 16 packets (exact parameters to be researched). This was shown to increase performance and eliminate stalls that happen otherwise. In this niche a nic that will understand the SACKs, and batch them for processing if they are just the common case of "additional x packets added to latest SACK block" would help in this regard. Reducing quite a bit of work the CPU needs to do otherwise. We still have the full Linux stack processing and reacting to the losses and doing the retransmits, we get the hardware to batch some of the work for us. This needs to be host assisted since we don't want this at the early stages of the connection, or for slow connections. Baruch - 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
