[RFC] [PATCH] usbatm.[ch]: logic changes + error handling

[Duncan Sands]

Hi Roman,

> This doesn't look feasible: usb layer wants contiguous DMA-able buffers,

contiguous?  See usb_sg_request.  Each piece should be contiguous, but
the whole needn't be.  DMA-able is true.

> while atm layer wants contiguous AAL5 PDUs.  Besides, copying the data
> is not at all that expensive (I'm pretty sure crc32 computation beats it
> by a huge margin).

Yes, the CRC computation shoots down the whole thing I think.

> The only possible improvement I can imagine here is
> making it a bit dcache-hotter: now we touch the data in 3 stages
> separated in time: fetch from usb, process in the tasklet, consume by
> atm (and vice versa in tx path).  But I still don't see a sensible
> algorithm to merge any two of these.  At any rate I would be very
> surprized if we are cpu-bound, so I think this all isn't really worth
> the hassle.

The less CPU we use, the more there is for everyone else...  Anyway,
some things could be improved.  For example, if we calculated the crc
progressively as we copy to the buffer (usbatm_write_cells) then we
should get better cache utilization.

Ciao,

D.