Date: Wed, 7 Jul 2004 22:38:33 +0200 From: Bernd Walter <ticso@cicely12.cicely.de> To: Julian Elischer <julian@elischer.org> Cc: FreeBSD current users <current@freebsd.org> Subject: Re: speeding up ugen by an order of magnitude. Message-ID: <20040707203832.GU12877@cicely12.cicely.de> In-Reply-To: <Pine.BSF.4.21.0407071137440.80217-100000@InterJet.elischer.org> References: <20040707095949.GF12877@cicely12.cicely.de> <Pine.BSF.4.21.0407071137440.80217-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@bwct.de info@bwct.de
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040707203832.GU12877>