Date: Mon, 21 Apr 1997 06:35:30 -0400 (EDT) From: Peter Dufault <dufault@hda.com> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: hasty@rah.star-gate.com, hackers@freebsd.org Subject: Re: video capture driver interface to file system? Message-ID: <199704211035.GAA24306@hda.hda.com> In-Reply-To: <199704210433.OAA07211@genesis.atrad.adelaide.edu.au> from Michael Smith at "Apr 21, 97 02:03:42 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> I was actually believing that it would cover the uiomove() time as > well, which looked to be the worst offender. Some more study tells > me this was wrong, so yes, I'd have to agree that a user-space > application is probably going to perform nearly as well. I'm assuming DMA directly into the user buffer via physio for a raw transfer. I use "raw transfer" always to mean directly to user buffers. I guess I need to use "cooked" or "psuedo-raw" transfers to describe transfers that uiomove indirectly through kernel buffers. >From Amancio's brief description I assume the device is capable of DMAing to anywhere in PCI memory. The only cool optimization I can think of is to use non-ascending transfers to DMA directly to a SCSI controller's data FIFO ... but we'll talk about that when we're trying to do 40MB/second to a disk array. (I've done exactly that in an HDTV research application four years back, though it was only 20MB/sec). Peter -- Peter Dufault (dufault@hda.com) Realtime Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704211035.GAA24306>