Alan Cox wrote:
> > I have made a patch for per connection fine tuning of keepalive messages
> > Let me know what do you think.
>
> First obvious comment. It doesn't enforce the 2hr timeout minimum. The
> minimum of 1 is wrong for some of those values.
Yes, the minimum values can be the values you decide they should be.
Even though from my experience with Tru64 and pSOS they can be as low as 1
(but of course I do not argue that these TCP stacks are the best).
>
>
> The real problem though is that you seem to be adding code for an
> utterly obscure feature to the fast tcp paths where everyone gets to pay
> for it.
Every socket is paying only few tests whether the keepalive option is enabled
on it or not.
Only sockets witch set keepalive option (so they are interested in keep-alive
processing)
go through the process of setting/deleting the timers.
In particular in the critical path of tcp_ack is the test
if (sk->keepopen) {
}
and I think that it does not slow anything because all the keepalive work is
within the condition.
And more - within the condition for keep-alive processing in the tcp_ack
function is the
optimization not to update the keep-alive timer not so often in bursts.
Pavel
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
