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

[Roman Kagan]

On Fri, Apr 15, 2005 at 12:31:01PM +0200, Duncan Sands wrote:
> On Fri, 2005-04-15 at 14:18 +0400, Roman Kagan wrote:
> > OK so here goes another update of my patch to the current CVS, in case
> > it gets somebody interested.
> 
> I'll get on to it after pushing the new infrastructure to gregkh.

Sigh...  That means I'll have to keep it in sync with CVS until then.
It's surely a tradeoff with stability, I just thought it can be
considered for inclusion before going upstream since we've passed
through major changes anyway.  OTOH a big delay in pushing it upstream
due to this patch isn't something I'd like, so...  I'll live with what
you decide :)

> By
> the way, I was musing about whether it is possible to avoid copying
> packets into a buffer at all by exploiting the scatter-gather
> infrastructure.  What gets sent to the modem?  Basically, blocks of data
> from the skb interspersed with padding and headers/trailers.  So
> couldn't you pass a scatter-gather thingy like this:
> 
> pointer 1 -> header
> pointer 2 -> start of data in skb
> pointer 3 -> next header thingy
> pointer 4 -> byte 48 of data in skb (or whatever it is)
> pointer 5 -> next header thingy
> 
> etc
> 
> Then you would only need to set up headers, you wouldn't need to
> copy the data.

This doesn't look feasible: usb layer wants contiguous DMA-able buffers,
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).  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.

Cheers,
  Roman.