[PATCH][RFC] usbatm.[ch]: cleanup and OAM F5 loopback

[Duncan Sands]

Hi Roman,

> > [...] (assuming packets are coming in faster than urbs are going
> > out, which could easily be true for small packets) you can pack your
> > many small packets into a spare buffer while waiting for a free urb,
> > then blast the whole lot off in one urb.  I always wondered if this
> > couldn't be done better using scatter-gather and some tricks.  I
> > think you understood what I was trying to do, but I'm confused by
> > "the submission of the current_sender is delayed".
> 
> Well, I had problems formulating that, but what you describe is more or
> less what happens.  The point is that when ATM data arrives, you have no
> way of knowing if more is going to come.  So, if the modem is busy
> digesting previously sent urbs, you can sit and wait for more data in
> the buffer, but if all urbs have completed you have to immediately push
> the data to the modem.  That's how it used to work and that's how I did
> it too, but using an atomic counter rather than an additional list.
> Still I'm curious if it's worth the hassle, and simply flushing the
> available data immediately is any slower.

it is probably pointless.  If more packets come in than you can send,
they get stuck on some queue anyway, and when a buffer/urb becomes
free you'll just copy in as many packets as you can before sending it.
Maybe once again the reason for this design was that in 2.4 days you
pretty much had to use only one urb, which you wanted to resubmit
instantly if possible - which meant having a buffer ready to go.
Nowadays with multiple queued urbs being no problem, I don't see
any advantage.

Ciao,

D.