Re: speeding up ugen by an order of magnitude.

    I explored the ugen code after reading Julian's original posting, 
    and Bernd Walter's very informative postings.  I also experimented 
    a bit with s10sh (which uses ugen to download from digital cameras).
    Unfortunately my camera probably isn't the best test, and I didn't
    get any huge improvement in performance... but it didn't break either,
    and the 1K on-kernel-stack buffer definitely has to be fixed in any case.

    My conclusion is that while a lot of copying occurs inside the kernel,
    (in at least two places in fact), the overhead is inconsequential
    relative to the 1 ms scan issue in the USB controller.  Remember, this
    is UGEN we are talking about here, not UMASS.  It is not necessary to
    squeeze out every last bit of performance, only to make the performance 
    'reasonable'. 

    The userland requests can certainly be made large enough (e.g. 64K,
    128K, 1MB, whatever) (s10sh uses a 4KB ugen request, for example, but
    can be easily increased).  The 1K buf[] in UGEN seems to be most
    responsible for screwing up performance.  Increasing this buffer to
    a reasonable size and ignoring the problem of data copying that occurs
    in-kernel basically moves the entire problem into the xHCI device layer.

    I would recommend that you guys simply increase the size of the buffer
    in the UGEN layer for now, along the lines of Julian's patch or my patch,
    and then work on making the xHCI layer deal with large requests more
    efficiently as a separate stage.  I email'd Julian the changes I made
    in DragonFly which include a sysctl to allow the buffer size to be 
    set/changed on the fly.  If you try to fix the half dozen or so 
    buffer copying / busdma issues as a pre-req, you will wind up getting
    nothing done at all.

						-Matt