> 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).
The flow cache would also be very useful to allow the NIC to send a MSI-X only to the CPU the user process did last recvmsg on. This way the receiving could be all CPU local and packets would need to be passed between CPUs. The process will likely stay on the same CPU due to CPU affinity, so this should work on average. This would need some state in the NIC, but it is much easier than full TOE because it doesn't have to be exact and is just a hint. If NIC and stack get desynchronized in some corner cases all that happens is that receiving goes slightly slower, but no data corruption can happen. I think that could be done with a single callback to the netdevice from when TCP frees the skb. -Andi - 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
