Re: if_txtimer API to replace (*if_watchdog)()

[Andrew Doran <ad%netbsd.org@localhost>]

On Thu, Jan 23, 2020 at 09:03:57AM -0800, Jason Thorpe wrote:

> > On Jan 23, 2020, at 8:10 AM, Andrew Doran <ad%netbsd.org@localhost> wrote:
> > 
> > How about permitting that but require that the lock is taken again before
> > return back to if_txtimer_tick().  Would it be a big pessimisation?  If
> > you're resetting the interface I guess not.
> 
> Well, it's not the only asymmetry...  in the "timer expired" case,
> if_txtimer_tick() also does not reschedule the callout (it relies on the
> callback's error handler to decide if that's appropriate).  Basically,
> "timer expired" == "driver handles the situation".  It just seems weird
> and redundant to require the callback to reacquire the lock just to have
> if_txtimer_tick() do nothing with it other than release it.

I'm not good with the network stack and have been avoiding it for years! 
All I can say is I don't have an objection to the pattern of handing off the
release if there's a decent justification for it.  We do the similar in the
scheduler in a few places if it's a dead end situation, or there's a cost in
holding the lock too long (e.g.  wake another CPU up which will immediately
slam into a lock curcpu holds).

Andrew