From owner-freebsd-arch@FreeBSD.ORG Sat Apr 25 18:45:52 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 93EC1F1C for ; Sat, 25 Apr 2015 18:45:52 +0000 (UTC) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 4FF1F1E25 for ; Sat, 25 Apr 2015 18:45:52 +0000 (UTC) Received: by oift201 with SMTP id t201so63202551oif.3 for ; Sat, 25 Apr 2015 11:45:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=KfCJrTiLG662wbxdgA798kUQP/T/rKzTiw5UnyjTcDw=; b=FmR1X8zMw5FTUz+e0IT8rk+eHEWClUdCFI3Yjtah0B3cT3Hrms2HFQ2PCvXajJjxjX adaSTtIb0gK/aZgYidn3qBR/Ngm3oZzMF6Dxuvhbb765j8ybM6eimYAyZL2wlM1T0hL5 Jt4C7JUxWNx7p6AXQGTNiab0Zwx5dHoiSWJQI1u3I3g9e/QMIYoBrQvvGBAs01UV+Y17 9uIFa4Hx/vQAU34h6nfTjymEnDPLRGsi/FDyycCoAgEOS/XXT9DaioqK8PznzAVeYFmq xa+k8WQ4tf6axuiQeuVg0rQBPVoGWXIUi5cBsDvf0zISXRSTeCVbd51AT01ktKUeBiAt 6bnw== X-Received: by 10.182.142.137 with SMTP id rw9mr3650023obb.83.1429987551648; Sat, 25 Apr 2015 11:45:51 -0700 (PDT) Received: from corona.austin.rr.com (cpe-72-177-6-10.austin.res.rr.com. [72.177.6.10]) by mx.google.com with ESMTPSA id gc7sm8539138obb.26.2015.04.25.11.45.50 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Apr 2015 11:45:51 -0700 (PDT) Message-ID: <553BE12B.4000105@gmail.com> Date: Sat, 25 Apr 2015 13:47:07 -0500 From: Jason Harmening User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Konstantin Belousov CC: Svatopluk Kraus , FreeBSD Arch Subject: Re: bus_dmamap_sync() for bounced client buffers from user address space References: <20150425094152.GE2390@kib.kiev.ua> <553B9E64.8030907@gmail.com> <20150425163444.GL2390@kib.kiev.ua> <553BC9D1.1070502@gmail.com> <20150425172833.GM2390@kib.kiev.ua> <553BD501.4010109@gmail.com> <20150425181846.GN2390@kib.kiev.ua> In-Reply-To: <20150425181846.GN2390@kib.kiev.ua> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nL5iEtE9e7JmsrptGRdbAV4CnLqkeTER2" 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: Sat, 25 Apr 2015 18:45:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nL5iEtE9e7JmsrptGRdbAV4CnLqkeTER2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 04/25/15 13:18, Konstantin Belousov wrote: > On Sat, Apr 25, 2015 at 12:55:13PM -0500, Jason Harmening wrote: >> Ah, that looks much better. A few things though: >> 1) _bus_dmamap_load_ma (note the underscore) is still part of the MI/M= D >> interface, which we tell drivers not to use. It looks like it's >> implemented for every arch though. Should there be a public and >> documented bus_dmamap_load_ma ? > Might be yes. But at least one consumer of the KPI must appear before > the facility is introduced. Could some of the GART/GTT code consume that? >> 2) There is a bus_dmamap_load_ma_triv that's part of the MI interface,= >> but it's not documented, and it seems like it would be suboptimal in >> certain cases, such as when dmar is enabled. > When DMAR is enabled, bus_dmamap_load_triv() should not be used. > It should not be used directly even when not. Drivers should use > bus_dmamap_load_ma(), and implementation redirects to _triv() if > needed. > > The _triv() is the helper to allow bus_dmamap_load_ma() to exists > on architectures which cannot implement, on not yet implemented, > proper page array load op. Yes, I noticed the same thing. I'm not sure why _triv() is treated as part of the public API and not prefixed with an underscore and a comment not to use it in drivers. >> 3) Using bus_dmamap_load_ma would mean always using physcopy for bounc= e >> buffers...seems like the sfbufs would slow things down ? > For amd64, sfbufs are nop, due to the direct map. But, I doubt that > we can combine bounce buffers and performance in the single sentence. In fact the amd64 implementation of uiomove_fromphys doesn't use sfbufs at all thanks to the direct map. sparc64 seems to avoid sfbufs as much as possible too. I don't know what arm64/aarch64 will be able to use.=20 Those seem like the platforms where bounce buffering would be the most likely, along with i386 + PAE. They might still be used on 32-bit platforms for alignment or devices with < 32-bit address width, but then those are likely to be old and slow anyway. I'm still a bit worried about the slowness of waiting for an sfbuf if one is needed, but in practice that might not be a big issue. --nL5iEtE9e7JmsrptGRdbAV4CnLqkeTER2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJVO+ErXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwAAoJELufi/mShB0b4MQIALHE02H9F1KBw7E6d75Q03Nk H7XaCvETTyNOQfxPLQ4Zs3FjRD3QbjsXavyqQA9XsAO8a9vMeDkUbKFaqIKWen4T zPAvEZ5RhWRnxRs0NNo/uvPCob7Or1GeE/kq9j0sxcVcvVVGa+xa4gCf6R+3aQ4Y rpEt72V4YyaPmr7e0nV6TTAjbJtbY4RxwbeSGuIlKcH+hHkfooRDWusEn8urOCVa bLzlrOZniwig6qG5s3fZ1oIRgWA9ngYy8jmh9RkEI/uhQeibJr1zJMCCu1Fg5ZQt V9STVSF2kyFlFqZVz+ENPGDEasjqAmgOwjHI4PF8WvujCLbO0h4OJZBkCMWLLD8= =aJCh -----END PGP SIGNATURE----- --nL5iEtE9e7JmsrptGRdbAV4CnLqkeTER2--