From owner-freebsd-arch@FreeBSD.ORG Tue Apr 28 19:10:44 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 914DA82E; Tue, 28 Apr 2015 19:10:44 +0000 (UTC) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 56962195F; Tue, 28 Apr 2015 19:10:44 +0000 (UTC) Received: by igblo3 with SMTP id lo3so29229362igb.0; Tue, 28 Apr 2015 12:10:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=YXXRMHR5TssIc7/XIinO/uAA5sROdLXc4Scm+HA05S8=; b=QgQ+MAmjok5hHzKoja4Fb4tNksyei5zkoB0bgU9mJG4BniruS7SNMR1bdfxLvSXBRM oRz5f76UmHSlmM5X3yKFFFo+yqqcpAGHckEh+NoAA67VdGnezBOkFW256vdO2Nj4duaq R9qZpvmMWAinVhAINX9aPrF4XzKbamEU2rIpYLIS54LN5kIkQZ7T6vj5Rll5/4s3MmS/ 45gc1VsrCb7Xx6X0o08oQRAfA5rxux+CpXoLMBQLmut1dN5Lc7FIaCu9x/Mq2/LyBHih g+TEmJPmIEaj7PryEiqLLy1JedboTPND60WcTp/XWm0ioUkfwzI2ct5HInz1hmfyswdt DAmw== MIME-Version: 1.0 X-Received: by 10.50.73.198 with SMTP id n6mr22560481igv.32.1430248243568; Tue, 28 Apr 2015 12:10:43 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Tue, 28 Apr 2015 12:10:43 -0700 (PDT) In-Reply-To: <38574E63-2D74-4ECB-8D68-09AC76DFB30C@bsdimp.com> References: <553B9E64.8030907@gmail.com> <20150425163444.GL2390@kib.kiev.ua> <1876382.0PQNo3Rp24@ralph.baldwin.cx> <38574E63-2D74-4ECB-8D68-09AC76DFB30C@bsdimp.com> Date: Tue, 28 Apr 2015 12:10:43 -0700 X-Google-Sender-Auth: 9H9hpSigDX-70d3_tIqGxz5PMEk Message-ID: Subject: Re: bus_dmamap_sync() for bounced client buffers from user address space From: Adrian Chadd To: Warner Losh Cc: John Baldwin , Konstantin Belousov , Jason Harmening , Svatopluk Kraus , freebsd-arch Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 19:10:44 -0000 On 28 April 2015 at 09:19, Warner Losh wrote: > >> On Apr 28, 2015, at 7:40 AM, John Baldwin wrote: >> >>> I believe UIO_USERSPACE is almost unused, it might be there for some >>> obscure (and buggy) driver. >> >> I believe it was added (and only ever used) in crypto drivers, and that = they >> all did bus_dma operations in the context of the thread that passed in t= he >> uio. I definitely think it is fragile and should be replaced with somet= hing >> more reliable. > > Fusion I/O=E2=80=99s SDK used this trick to allow mapping of userspace bu= ffers down > into the block layer after doing the requisite locking / pinning / etc of= the buffers > into memory. That=E2=80=99s if memory serves correctly (the SDK did these= things, I can=E2=80=99t > easily check on that detail since I=E2=80=99m no longer at FIO). This is a long-standing trick. physio() does it too, aio_read/aio_write does it for direct block accesses. Now that pbufs aren't involved anymore, it should scale rather well. So I'd like to see more of it in the kernel and disk/net APIs and drivers. -adrian