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

[Duncan Sands]

Hi Roman,

>  1) removes the distinction between sending and receiving buffers, and
>     sticks the buffer with the urb to serve it onto the struct
>     usbatm_transceiver, which is to replace structs usbatm_receiver,
>     usbatm_sender, usbatm_receive_buffer and usbatm_send_buffer;

I haven't looked at your patch yet, but maybe I should explain why
there are currently more buffers than urbs (at least I think this is
why - it's been a while since I wrote it...), and urbs and buffers
are decoupled.  When receiving, this allows the completed urb to be
immediately resubmitted (with a different buffer), rather than
having to wait for the buffer to be processed into packets before
resending.  It used to be that queueing multiple urbs was not reliable
(2.4 days), in which case you only had one receive urb.  So this was
an attempt to get as close as possible to always having an urb queued
on the endpoint.  Nowadays there is no problem having many urbs queued,
so this optimization (which probably never gained you anything much)
can be dropped I think.  When sending, having more buffers than urbs
means that (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".  I don't remember
anything like that, but that's not saying much :)

> In addition, I've put in some code to reply to OAM F5 Loopback cells
> without passing them to the ATM layer (F4 should be easy too).
> Unfortunatly I have no way to test it, my ISP doesn't use it.  I had to
> include crc10 lookup table, which may eventually be factored out into a
> library module; this explains why the diffstat is not that cool :)

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?

Ciao,

D.