updated patch with throttling

Duncan Sands baldrick at free.fr
Fri Mar 25 08:01:39 EST 2005

> > 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).  It would make more sense to fail packets if an urb they
are in fails (but how - the buffer doesn't know which skbuffs were used
to fill it), and also do some throttling.



More information about the Usbatm mailing list