tcp_isn_tick() / dummynet() callout madness ?

[Mike Silbersack]

On Sun, 30 Jan 2005, Mike Silbersack wrote:

> 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.

Ok, thinking about it just a little more, the "next" field would have to 
be stored in the callout structure, and it would have to be unsychronized. 
We'd have to assume that it would ONLY be updated by a callout handler, 
which is why sychronization would be safe.

Example:

tcp_isn_tick_callout fires
+ tcp_isn_tick_callout rescheduled to fire at "next" time
tcp_isn_tick routine is executed
+ tcp_isn_tick_callout.next is set for whatever time it should fire after 
the next firing

Does that make sense?  It allows for routines to schedule themselves on a 
fixed schedule or on a mildly variable schedule.  If they guessed wrong on 
what "next" should be, then they'd just use callout_reset to change the 
scheduling, and incur the cost they do right now for every reschedule.

Mike "Silby" Silbersack