From owner-freebsd-arch@FreeBSD.ORG Fri Jun 27 12:50:09 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 6E67337B401 for ; Fri, 27 Jun 2003 12:50:09 -0700 (PDT) Received: from magic.adaptec.com (magic-mail.adaptec.com [208.236.45.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id E130943FBF for ; Fri, 27 Jun 2003 12:50:08 -0700 (PDT) (envelope-from scott_long@btc.adaptec.com) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.11.6/8.11.6) with ESMTP id h5RJnI815838; Fri, 27 Jun 2003 12:49:18 -0700 Received: from btc.adaptec.com (hollin.btc.adaptec.com [10.100.253.56]) by redfish.adaptec.com (8.8.8p2+Sun/8.8.8) with ESMTP id MAA22244; Fri, 27 Jun 2003 12:50:08 -0700 (PDT) Message-ID: <3EFC9F2D.6020908@btc.adaptec.com> Date: Fri, 27 Jun 2003 13:46:53 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3) Gecko/20030414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Gallatin References: <3EF3C12F.9060303@btc.adaptec.com> <16124.39930.142492.356163@grasshopper.cs.duke.edu> In-Reply-To: <16124.39930.142492.356163@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-arch@freebsd.org Subject: Re: API change for bus_dma 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: Fri, 27 Jun 2003 19:50:09 -0000 Andrew Gallatin wrote: > Scott Long writes: > > All, > > > > As I work towards locking down storage drivers, I'm also preening their > > use of busdma. A common theme among them is a misuse of > > bus_dmamap_load() and the associated callback mechanism. For most, the > > Why not just add a way to avoid deferring the callback entirely? I'm > talking about something like Solaris' ability to pass DDI_DMA_DONTWAIT > as the callback function to ddi_dma_buf_bind_handle(). > As you hinted below, BUS_DMA_NOWAIT does what you want. It will return ENOMEM to the caller if the bounce buffers cannot be pre-allocated during bus_dmamap_load(). > My desire is to know immediately whether the DMA mapping failed. If > it failed, that's OK with me. Since my driver locks users memory and maps > it for DMA for a potentially unbounded amount of time, I want to > know about a failure right away, not pile up requests that will never > be satisfied. bus_dmamap_load() is designed to always return immediately with either sucess (meaning that the callback was called), or some sort of error code. A return of EINPROGRESS means that bouncing was required but bounce buffers were not available so the callback was defered. There is a flaw in that bus_dmamap_load() treats every request individually. If a request comes in that has to be deferred, and a second request comes in that doesn't need to be deferred, it's likely that the second request will be serviced before the first. SCSI drivers (that check EINPROGRESS correctly) get around this by telling CAM to freeze the queue until the deferred request is serviced. The better solution is probably for bus_dmamap_load() to defer any new requests while prior ones are still pending. Scott