Date: Tue, 30 Dec 2014 22:09:02 +0530 From: Shivaram Upadhyayula <shivaram.u@quadstor.com> To: "Kenneth D. Merry" <ken@freebsd.org> Cc: freebsd-scsi@freebsd.org Subject: Re: Tape block size greater than MAXPHYS Message-ID: <CAN-_EfyaSUGOXZKW-wP4DAw0kGSpf%2Bm30q5RndXT3B7kUNjA6A@mail.gmail.com> In-Reply-To: <20141230063129.GA77314@mithlond.kdm.org> References: <CAN-_EfxSk8nsoVLGi=Z4E-ejb6ynyCE1PHvNkpz0pWYo-PfqPg@mail.gmail.com> <20141230063129.GA77314@mithlond.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 30, 2014 at 12:01 PM, Kenneth D. Merry <ken@freebsd.org> wrote: > On Mon, Dec 29, 2014 at 14:52:12 +0530, Shivaram Upadhyayula wrote: <...> > One problem that was there before the SI_NOSPLIT changes and is still > present is that we can't by default read tapes with a large blocksize (e.g. > 1MB). Increasing MAXPHYS will certainly fix it (assuming your controller > sets the maxio field in the path inquiry CCB to something sufficiently > large). I have considered adding a custom read/write routine to the sa(4) > driver that would essentially take the best available path given the > requested block size and the constraints imposed by the controller and > MAXPHYS. > > The logic would be something like: > - If the I/O is <= MAXPHYS (including alignment constraints) and the > controller supports it, do unmapped I/O. > - Otherwise, allocate buffers from a sa(4)-specific UMA zone and copy in > and out. This would allow for doing I/O up to the controller's limit, > without regard for MAXPHYS. On modern machines, this would also usually > be faster than mapping the memory in and out of the kernel, because you > avoid the extra TLB shootdowns. > > Ideally we'll get a scheme in place to allow doing unmapped S/G lists at > some point. But we don't have that yet. > > I have some code with logic similar to the above scenario for the pass(4) > driver asynchronous mode that I has been in my queue to upstream for about > a year. Where can the passthrough driver patch be accessed ? Thanks, Shivaram
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAN-_EfyaSUGOXZKW-wP4DAw0kGSpf%2Bm30q5RndXT3B7kUNjA6A>