Re: speeding up ugen by an order of magnitude.

On Wed, Jul 07, 2004 at 12:20:35PM -0700, Julian Elischer wrote:
> 
> 
> On Wed, 7 Jul 2004, Bernd Walter wrote:
> 
> > On Wed, Jul 07, 2004 at 11:16:14AM +0200, Poul-Henning Kamp wrote:
> > > In message <20040707091311.GE12877_at_cicely12.cicely.de>, Bernd Walter writes:
> > > >On Tue, Jul 06, 2004 at 04:32:28PM -0700, Julian Elischer wrote:
> > > 
> > > >What about those options:
> > > >- limit the allocated memory to the user request so we don't take the
> > > >  whole 128k if not reuired.
> > > >- Do interleaving with 2 or more xfers if the read request is known to
> > > >  take more xfers.
> > > 
> > > I would consider ugen to be a primary candidate to use physio like
> > > I belive scsi-tape drives do ?
> > 
> > I don't really know the points between physio and the current way.
> > The story with USB bulk transfers is that legal transfers can have a
> > data size of even down to 0 bytes and a lot a typical clients do
> > small transfers - just depends on the designers needs.
> 
> I might add that the INTERRUPT mode code for ugen
> does things in turn of 128 byte chunks, but for USB2
> devices it is now permissable to use chunks of up to 1024 bytes.
> we should probably make that adjustable depending on whether the device
> is a USB 2 one or not..

The number of bytes for interrupt endpoints is controlled by the
endpoint descriptor of the device - high speed or not.
An USB2 device shouldn't define 1024 byte interrupt endpoints when
only running full speed.
It's also legal for a USB2 device to be full speed only - not to
speak from attaching a high speed capable device to a full speed
controller.
You can sanity check the allowable size for interupt endpoints but
you are not allowed to do transfers of any other size then the
endpoint descriptor tells.
I did devices with 8 byte interrupt endpoints myself and had no
problems with ugen - are you shure about the 128 bytes?

>  Ther eis a lot to be done here to make this code really USB-2 code
> as opposed to USB-2 "aware" code.
> 
> 
> > In the current code it seems that short transfers are already broken
> > at least I don't see where short transfers can break out of the while
> > loop so the knowledge about the real transfers size is lost.
> > Under normal conditions we should break out on short transfers and
> > return the so far transfered size.
> > We should also be able to do interleaving some day.
> > If you think that the requirements wouldn't collide with physio then
> > OK.
> 
> Physio simply transforms a transfer into user space in a way that the
> transfers don't require a buffer, but rather, use the user's buffer
> pages as the direct target of the transfer. You need to supply a 
> "strategy" routine that does both read and write to the mapped buffers
> on behalf of physio and it tends to use system "buf" structs.

OK - that really sounds like a great idea.

> > Nevertheless I see ugen more as a quick and dirty way to test drive a
> > device from userland with all it's great debugging capabilities before
> > writing a specific kernel driver.
> > The requirement that ugen has to be generic is often bad for
> > performance sensitive applications.
> 
> Ugen is used in production all over the place where people have to used
> devices there is no specific support for, and where there is no
> kernel expertise.

Yes - and not all usage of bulk endpoints is for high bandwidth
transfers.
USB is polling as you know - so every application that waits for data
on an endpoint has an outstanding read transfer.
However - physio invalidates the whole malloc size discussion.

-- 
B.Walter                   BWCT                http://www.bwct.de
bernd_at_bwct.de                                  info_at_bwct.de