From owner-freebsd-scsi@FreeBSD.ORG Tue Dec 30 16:39:11 2014 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 32CD66A6 for ; Tue, 30 Dec 2014 16:39:11 +0000 (UTC) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BEDAB291F for ; Tue, 30 Dec 2014 16:39:10 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id y19so20973204wgg.28 for ; Tue, 30 Dec 2014 08:39:03 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YSwWRH6H7Ym09tsVlhlAZY1TjzpvOeg/lxAWsD9aqTM=; b=ctpe484/F+JjnyeQVH2iJ50iYXSn+axAoPW4K15z58hi5K0ZUZBzV1wlsrqWMfh5mS dVv916oyR9PXXFXHwasa5CdPZgfErYRcnvfqld9oZblHUZZjkdDVvvIZKhcQP+zVccZb ODIlK+9L9mmV17njyorrTAc+IjJ7PMDLNRRLskTKIsrE5+6gTwULny9mu50JgZMC7keZ +Jkk2UoVgj/THwobTX3kTADn5pAfjRT6FX4PVHfK8riFiHf/3Pvumjr3sqvjcpfxaFnP y9HsbbGpLv09D9mxyWrM3OUODiZ6PD/0aQaDsW6Anv5ya9cM0/t5wC58kmdAA7OIXf86 QArw== X-Gm-Message-State: ALoCoQmucburoe7plTcyrAPMTif1XocGidQwloldpN4pnqAIcKcTkL6gwbtLl8vQx8KDmGxHWBHZ MIME-Version: 1.0 X-Received: by 10.180.85.4 with SMTP id d4mr106867308wiz.36.1419957542955; Tue, 30 Dec 2014 08:39:02 -0800 (PST) Received: by 10.217.106.202 with HTTP; Tue, 30 Dec 2014 08:39:02 -0800 (PST) X-Originating-IP: [117.221.20.54] In-Reply-To: <20141230063129.GA77314@mithlond.kdm.org> References: <20141230063129.GA77314@mithlond.kdm.org> Date: Tue, 30 Dec 2014 22:09:02 +0530 Message-ID: Subject: Re: Tape block size greater than MAXPHYS From: Shivaram Upadhyayula To: "Kenneth D. Merry" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-scsi@freebsd.org X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 16:39:11 -0000 On Tue, Dec 30, 2014 at 12:01 PM, Kenneth D. Merry 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