updated patch with throttling

[Roman Kagan]

On Fri, Mar 25, 2005 at 02:01:39PM +0100, Duncan Sands wrote:
> > > Below is the updated patch which avoids both deadlock and livelock in
> > > case of repetitive urb submission failures.  It does that by adding two
> > > timers (for either direction) to make sure the processing is restarted
> > > after the submission error but with a delay of THROTTLE_MSECS which I
> > > arbitrarily set to 5.
> > Do we realy need a timer for sending ?
> > The atm layer, should call tasklet_schedule in usbatm_atm_send ?
> > 
> > Also now that tasklet_schedule is call each time a urb complete, when
> > tasklet_schedule could deadlock ?
> 
> Hi Matthieu, I guess the problem is the tasklet scheduling all the time,
> keeping the system busy eternally rescheduling urbs that keep on
> failing.  Part of the current logic for sending (I now remember) is that
> if urbs fail on submission, then they are retried when the next packet
> comes in for sending.  But this isn't good enough, because the ATM
> limits the number of bytes waiting to be sent, and won't send more when
> the limit is reached.  So all buffers could fill up, and then everything
> would get stuck (not the end of the world, but the end of the
> connection).

Right, and for reception it's even worse: if you happen to fail to
submit all urbs you have (and we usually have very few, default 2
originally and 4 in my patch), then they'll never complete and noone
will reschedule the tasklet.

Roman.