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

[Roman Kagan]

On Fri, Mar 11, 2005 at 09:48:24PM +0100, Duncan Sands wrote:
> [...] maybe I should explain why there are currently more buffers than
> urbs [...] and urbs and buffers are decoupled [...]

AFAICT it works about the same in the patch, except that urbs whose
buffers are being processed are left "idle".

> [...] (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.

> I agree that we need to support OAM (we need to add special tx/rx
> paths), but this doesn't sound like the right approach.  Shouldn't
> the ATM layer handle this bit?

Yep, that's the problem: passing the OAM cell up to the ATM layer is
more trouble than replying to it in the driver.  Just look at the OAM
stuff in the linux-atm: 90% of it is additional infrastructure.  If it
ever gets into the kernel proper, and we want full-fledged OAM support,
we'll be able to adjust easily.  But for now it should enable people
whose ISPs requre OAM loopback replies to use usbatm.  Besides, AFAICS
some ATM drivers do OAM in hardware, so we can pretend we do too... :)

Cheers,
  Roman.