From owner-freebsd-arch@FreeBSD.ORG Tue Oct 7 03:35:40 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABA6D16A4B3; Tue, 7 Oct 2003 03:35:40 -0700 (PDT) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DE0543F3F; Tue, 7 Oct 2003 03:35:39 -0700 (PDT) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h97AWu868742; Tue, 7 Oct 2003 06:32:56 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Tue, 7 Oct 2003 06:32:56 -0400 (EDT) From: Jeff Roberson To: Harti Brandt In-Reply-To: <20031007091948.N57124@beagle.fokus.fraunhofer.de> Message-ID: <20031007063207.V99666-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: arch@freebsd.org cc: Poul-Henning Kamp cc: Garrett Wollman Subject: Re: Alignment of disk-I/O from userland. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2003 10:35:40 -0000 On Tue, 7 Oct 2003, Harti Brandt wrote: > On Mon, 6 Oct 2003, Scott Long wrote: > > SL>On Mon, 6 Oct 2003, Poul-Henning Kamp wrote: > SL>> In message <200310062146.h96Lkpx0093486@khavrinen.lcs.mit.edu>, Garrett Wollman > SL>> writes: > SL>> > SL>> >I think that gives us plenary authority to require appropriate > SL>> >alignment of data buffers used to access disk devices directly. > SL>> > SL>> Well, apart from us wedging or botching the request rather than > SL>> return a consistent error we're standards compliant then. > SL>> > SL>> It has been mentioned on #thatchannel that busdma should take care > SL>> of this by copying the request as necessary. Faced with the prospect > SL>> of a request several megabytes in size, I don't like the prospect > SL>> of malloc/bcopy too much. > SL> > SL>Working around hardware requirements from the block layer gets messy. > SL>You obviously don't want to manually align buffers that are distined > SL>for hardware that doesn't care about the alignment. How do you > SL>communicate this property upwards from the driver? Callbacks? Extra > SL>flags in disk_create()? It's all rather messy that way. We already > SL>have the busdma interface whose sole purpose is to take system > SL>buffers and prepare them for transfer to/from hardware. It already > SL>understands the concept of alignment, though it only applies it to > SL>buffers that it allocates, not buffers that are handed to it. Fixing > > This seems to be not true. The alignment parameter for the busdma tag is > more or less ignored in all backends. With the old malloc code you could > simply make sure that the buffer you request is at least the size of > alignment you need. With UMA this doesn't work anymore. I bumped into this > problem while writing several ATM drivers which need alignment of 16 or 32 > byte. At the moment the driver does this alignment itself by allocating a > large enough dmamem buffer and fiddling with the pointers. I don't believe that this is the case with UMA. Too many things depended on this behavior and so I left it in. > > harti > > SL>that would be easy, and would allow for optimizations based on the > SL>bus (GART and IOMMU remapping). It also keeps the property down at > SL>the device driver where it belongs. > SL> > SL>As for returning an error code for a buffer that we (arbitrarily) believe > SL>to be too big to align, I'm not sure that it's a valid thing to worry > SL>about. People expect their hardware to Just Work, regardless of how cheap > SL>it is. If someone buys a cheap card with a cheap DMA engine, their cost > SL>comes in from higher system time per I/O. If they don't like that, they > SL>can complain to the manufacturer and/or buy a better card. I'm not aware > SL>of Linux nor OSX rejecting I/O based on arbitrary size limits. > SL> > SL>Scott > SL>_______________________________________________ > SL>freebsd-arch@freebsd.org mailing list > SL>http://lists.freebsd.org/mailman/listinfo/freebsd-arch > SL>To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > SL> > > -- > harti brandt, > http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private > brandt@fokus.fraunhofer.de, harti@freebsd.org > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" >