Re: tcp_isn_tick() / dummynet() callout madness ?

On Sun, 30 Jan 2005, Robert Watson wrote:

> On Sun, 30 Jan 2005, Mike Silbersack wrote:
>
>> change to the callout API?  Just a few places in the kernel account for
>> most of the use of callouts, so even if a rewrite of those would be
>> necessary, it should pay off.
>
> Well, part of the problem is that many callouts always re-register, and
> right now they're forced to pay a penalty for it.  I almost wonder if we
> shouldn't add a new flag or method to swap the costs: register a recurring
> callout every (x) ticks, and you pay a cost to unregister it if the flag
> is set, and the callout is otherwise automatically rescheduled.
>
> Robert N M Watson

That sounds worthwhile.  For things like tcp_isn_tick, it'd be perfect.

For the per-socket TCP timers, here's what I've been pondering for a 
while.  Right now, we use seperate callouts for retransmit, 2msl, 
keepalive, delayed ack, etc.  If we made the code just a little bit 
smarter (and that would be easy with some quick macros), we could bring 
each socket down to a single callout.  That callout, whenever triggered, 
would look through the per-socket data and see which of the different 
timers was the one that just fired, and run it.  Since the keepalive 
callout is almost never fired, but always rescheduled, that'd be a big 
win.

This could be used with your auto-reschedule idea; perhaps the way 
auto-reschedule would work is that each callout has a next callout time 
set.  So, suppose that we have a delayed ack timeout happening in 50ms, 
and a potential retransmit timeout happening in 4 seconds.  We'd set the 
per-socket callout for 50ms, with a next time of 4 seconds.  When the 
callout fires, it'll be rescheduled for 3.95 seconds from now, and if 
that's wrong, we'll just have to incur the cost of rescheduling it.

But, in the case of the next time being correct, that would be much more 
efficient.

Mike "Silby" Silbersack