Date: Wed, 9 Apr 2003 14:09:26 -0600 From: "Kenneth D. Merry" <ken@kdm.org> To: "John S. Bucy" <bucy@ece.cmu.edu> Cc: freebsd-scsi@freebsd.org Subject: Re: cam: big transfers Message-ID: <20030409140925.A12401@panzer.kdm.org> In-Reply-To: <20030409140158.A12245@panzer.kdm.org>; from ken@kdm.org on Wed, Apr 09, 2003 at 02:01:58PM -0600 References: <20030409194237.GI7726@catalepsy.ece.cmu.edu> <20030409140158.A12245@panzer.kdm.org>
index | next in thread | previous in thread | raw e-mail
On Wed, Apr 09, 2003 at 14:01:58 -0600, Kenneth D. Merry wrote: > On Wed, Apr 09, 2003 at 15:42:38 -0400, John S. Bucy wrote: > > > > Is it possible to do large (>MAXPHYS) bus transfers from a userland process > > via cam? > > Not currently, no. You'd need to do some hacking around in > cam_periph_mapmem() to allow for larger buffers. It actually checks > against DFLTPHYS (64K) at the moment, not MAXPHYS, since some adapters > (e.g. the Adaptec 1542) can't handle more than 17 S/G segments. > > If you just need larger buffers, and not performance, you could malloc a > new kernel-space buffer to hold the user data. I forgot the finish the thought there. You'd need to copy the data in and out in that case. > If you want performance as well, you could try writing your own routine > that would map N pages from userland into the kernel, where N would be > greater than MAXPHYS/PAGE_SIZE. > > If you just need say 256K transferred at a time, you could try bumping > MAXPHYS to that and changing cam_periph_mapmem() to check against MAXPHYS > as long as your hardware can support that. > > Ken > -- > Kenneth Merry > ken@kdm.org > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" Ken -- Kenneth Merry ken@kdm.orghelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030409140925.A12401>