From owner-freebsd-arm@FreeBSD.ORG Tue Dec 25 03:13:18 2012 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CBF3231C for ; Tue, 25 Dec 2012 03:13:18 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm19.bullet.mail.bf1.yahoo.com (nm19.bullet.mail.bf1.yahoo.com [98.139.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id 67B9E8FC0A for ; Tue, 25 Dec 2012 03:13:18 +0000 (UTC) Received: from [98.139.215.140] by nm19.bullet.mail.bf1.yahoo.com with NNFMP; 25 Dec 2012 03:13:12 -0000 Received: from [98.139.213.3] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 25 Dec 2012 03:13:12 -0000 Received: from [127.0.0.1] by smtp103.mail.bf1.yahoo.com with NNFMP; 25 Dec 2012 03:13:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1356405192; bh=ienAAZglLtbBNsor83kO6OPNJsGRWpJRYSiVFT0tQqw=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=wdoP2wMZR800NZ1nu3hDEgMbqcUgrU4R6p1JvMo4WC/4WqzUgf0YjR6BPTcpX+BVwbrF24rMf+rAPg/Kx66E0tVLSTnJbcLMc1uYaWiN8M2bKV1W0jZb9nzik4rjGahChw00xzosT/Hhwqn8DpBZDdMxrE46h/ihvMhbmAvaBmA= X-Yahoo-Newman-Id: 233465.49273.bm@smtp103.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: hDJW8PcVM1l0iy7KkxW1my2pYpqQMHhtseGfw0da88jRdvm gZ1.GIEeIuDLxMoMe6aCGrkTFDyGvMjfolt4MSQYbUHvixI7WwqtgfCbEzlv 4kLqDypbFZ5vpFWVoV7gyYLZblUnYRWwrs2Gjr2V1fyJPcbNsJd8Wg28c_tQ q4K6qDqcysRxLx5T9Wkmr33IxW9rtMUqLTqa9drxawgScADW.UHHqTQ4QLBx HYzNzh.Kj.gC72PUl1dTGcOXxQYgdyx3bZGc6piUmTNddjWRrdzJqYAtJ0x0 hA.2LykQZioWy1OE5732MLw3_Iv1HoKQP43wiYMzo3ty4muqFsvFf6SRvG.A 7R0oygCNlF_sEo.BBPQ96aF83fVlNqD1jZvbVwGbCQScWUg5tHORsjbTudGr j0m8y5OmDN.luvwy0VxK0eXgwKvqFwnYW1IVdtoHRHwVbJySQcYkpoUx_Ze7 RF3WY.CdyYvx7Tg-- X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- Received: from [172.20.10.3] (scott4long@70.193.200.44 with plain) by smtp103.mail.bf1.yahoo.com with SMTP; 24 Dec 2012 19:13:12 -0800 PST Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Call for testing and review, busdma changes From: Scott Long In-Reply-To: <1356390225.1129.217.camel@revolution.hippie.lan> Date: Mon, 24 Dec 2012 22:13:10 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2D98F70D-4031-4860-BABB-1F4663896234@yahoo.com> References: <1355077061.87661.320.camel@revolution.hippie.lan> <1355085250.87661.345.camel@revolution.hippie.lan> <1356381775.1129.181.camel@revolution.hippie.lan> <1356390225.1129.217.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Tue, 25 Dec 2012 03:28:41 +0000 Cc: powerpc@freebsd.org, marcel@freebsd.org, mips@freebsd.org, John Baldwin , "mav@freebsd.org Motin" , "attilio@FreeBSD.org Rao" , Jeff Roberson , sparc64@freebsd.org, arm@freebsd.org, kib@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2012 03:13:18 -0000 On Dec 24, 2012, at 6:03 PM, Ian Lepore = wrote: >=20 > Yeah, I've done some low-level storage driver stuff myself (mmc/sd) = and > I can see how easy the deferred load solutions are to implement in = that > sort of driver that's already structured to operate asychronously. = I'm > not very familiar with how network hardware drivers interface with the > rest of the network stack. I have some idea, I'm just not sure of all > the subtleties involved and whether there are any implications for > something like a deferred load. >=20 > This is one of those situations where I tend to say to myself... the > folks who designed this stuff and imposed the "no deferred load" > restriction on mbufs and uio but not other cases were not stupid or > lazy, so they must have had some other reason. I'd want to know what > that was before I went too far with trying to undo it. >=20 Deferring is expensive from a latency standpoint. For disks, this = latency was comparatively small (until recent advances in SSD), so it = didn't matter, but it did matter with network devices. Also, network = drivers already had the concept of dropping mbufs due to resource = shortages, and the strict requirement of guaranteed transactions with = storage didn't apply. Deferring and freezing queues to guarantee = delivery order is a pain in the ass, so the decision was made that it = was cheaper to drop an mbuf on a resource shortage rather than defer. = As for uio's, they're the neglected part of the API and there's really = been no formal direction or master plan put into their evolution. = Anyways, that's my story and I'm sticking to it =3D-) Also, eliminating the concept of deferred load from mbufs then freed us = to look at ways to make the load operation cheaper. There's a lot of = code in _bus_dmamap_load_buffer() that is expensive, but a big one was = the indirect function pointer for the callback in the load wrappers. = The extra storage for filling in the temporary s/g list was also looked = at. Going with direct loads allowed me to remove these and reduce most = of the speed penalties. >=20 >>>=20 >>> Still unresolved is what to do about the remaining cases -- attempts = to >>> do dma in arbitrary buffers not obtained from bus_dmamem_alloc() = which >>> are not aligned and padded appropriately. There was some discussion = a >>> while back, but no clear resolution. I decided not to get bogged = down >>> by that fact and to fix the mbuf and allocated-buffer situations = that we >>> know how to deal with for now. >>=20 Why would these allocations not be handled as normal dynamic buffers = would with bus_dmamap_load()? Scott