From: "Leonid Grossman" <[EMAIL PROTECTED]> Date: Sat, 20 Aug 2005 21:17:19 -0400
> OLS.pdf at ftp ns1.s2io.com user: linuxdocs password: HALdocs Looks good, the LRO bits. It seems important that the OS can specify the LRO sizing limits. Even better, it would help also to have a flow cache of some sort that can remember some kind of state. Here's why. Early in the connection you can't use a large limit because the congestion window is still growing. So if it's beyond a few packets, you'll hit the LRO timeout for the first couple of round trips. If you have a flow cache, keyed on saddr/daddr/sport/dport then you can keep a growing LRO limit. For example, when a flow cache entry is created, use a LRO limit of 2 frames. Each time the LRO limit is reached, increase the LRO limit by one (until you hit the largest LRO supported, which for ipv4 would be 64K minus header space). 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. - 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
