From owner-freebsd-hackers@FreeBSD.ORG Fri Jul 6 20:41:43 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7012A16A41F; Fri, 6 Jul 2007 20:41:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id EB69A13C45B; Fri, 6 Jul 2007 20:41:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l66KfcTm036933; Fri, 6 Jul 2007 16:41:38 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Hans Petter Selasky Date: Fri, 6 Jul 2007 16:41:35 -0400 User-Agent: KMail/1.9.6 References: <200707040901.33019.hselasky@c2i.net> <200707051935.32880.jhb@freebsd.org> <200707060859.39816.hselasky@c2i.net> In-Reply-To: <200707060859.39816.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707061641.36396.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 06 Jul 2007 16:41:38 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3607/Thu Jul 5 19:51:19 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-hackers@freebsd.org, John-Mark Gurney , freebsd-usb@freebsd.org Subject: Re: New USB stack and Zero copy. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2007 20:41:43 -0000 On Friday 06 July 2007 02:59:39 am Hans Petter Selasky wrote: > On Friday 06 July 2007 01:35, John Baldwin wrote: > > On Thursday 05 July 2007 04:25:17 pm John Baldwin wrote: > > > On Thursday 05 July 2007 03:31:59 am Hans Petter Selasky wrote: > > > > On Wednesday 04 July 2007 19:35, John-Mark Gurney wrote: > > > > > Hans Petter Selasky wrote this message on Wed, Jul 04, 2007 at 09:01 > > > > > > +0200: > > > > > > Also: How is the easiest way to load memory pages into DMA ? And I > > > > want > > > > > > > > that the loadig works like this, that when the page must be bounced > > > > > > it should not allocate a bounce buffer, hence I already have a > > > > > > bounce buffer. I only need to know which pages I can forward > > > > > > directly to the > > > > > > USB > > > > > > > > > hardware, and the rest I will bounce somewhere else. > > > > > > > > > > Why do you not want to let bus_dma do the bouncing for you? If it's > > > > > to save a copy to another buffer, why don't you load the final buffer > > > > > into bus_dma? > > > > > > > > Because if I let bus_dma do the bounching, I cannot do this while > > > > holding > > > > a > > > > > > mutex, hence allocating DMA'able memory on the fly is not so good. > > > > > > This is not a hard problem to solve, every other driver using bus_dma > > > solves it. Just make sure your driver is in a sane state and drop the > > > lock while you let bus_dmamap_load() map/copy things for you. > > > > Bah, backwards (was thinking of the fact that if you get EINPROGRESS you > > will have to drop the lock and just wait until the callback is called to > > make further progress on the request). bus_dmamap_load() already > > _requires_ you to hold your mutex when you call it, so I don't really see > > what the issue is, unless you are assuming BUS_DMA_NOWAIT behavior and > > can't properly handle deferred callbacks. You do have to drop the lock > > around bus_dmamem_alloc(), but not bus_dmamap_load(). > > The thing is that allocating memory on the fly will be slow, and especially > when the xxxx_load() functions will allocate contiguous memory. This only > works fine when you load mbufs and things with size less than PAGE_SIZE > bytes ?? Huh? The bounce pages are preallocated, so bus_dmamap_load() isn't going to be allocating things. -- John Baldwin