lkml.org 
[lkml]   [2006]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: TSO and IPoIB performance degradation
> Wouldn't it make sense to strech the ACK when the previous ACK is still in 
> the TX queue of the device? I know that sort of behaviour was always an
> issue on modem links where you don't want to send out redundant ACKs.

Perhaps, but it isn't clear that it would be worth the cycles to check.
I doubt that a simple reference count on the ACK skb would do it
since if it were a bare ACK I doubt that TCP keeps a reference to the
skb in the first place?

Also, what would be the "trigger" to send the next ACK after the
previous one had left the building (Elvis-like)? Receipt of N in-order
segments? A timeout?

If you are going to go ahead and try to do stretch-ACKs, then I suspect
the way to go about doing it is to have it behave very much like HP-UX
or Solaris, both of which have arguably reasonable ACK-avoidance
heuristics in them.

But don't try to do it quick and dirty.

rick "likes ACK avoidance, just check the archives" jones
on netdev, no need to cc me directly
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-03-20 20:01    [W:0.156 / U:0.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site