Re: TSO and IPoIB performance degradation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux