From owner-freebsd-arch@FreeBSD.ORG Fri Sep 28 15:53:17 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A30616A41A for ; Fri, 28 Sep 2007 15:53:17 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id CE4F813C459 for ; Fri, 28 Sep 2007 15:53:16 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] Received: from [85.19.218.45] (account mc467741@c2i.net [85.19.218.45] verified) by mailfe07.swip.net (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 631171706; Fri, 28 Sep 2007 17:53:14 +0200 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Fri, 28 Sep 2007 17:53:29 +0200 User-Agent: KMail/1.9.7 References: <200709260131.49156.hselasky@c2i.net> <200709262157.02712.hselasky@c2i.net> <46FB03B1.6020100@samsco.org> In-Reply-To: <46FB03B1.6020100@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709281753.30367.hselasky@c2i.net> Cc: Scott Long Subject: Re: Request for feedback on common data backstore in the kernel X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Sep 2007 15:53:17 -0000 On Thursday 27 September 2007, Scott Long wrote: > Hans Petter Selasky wrote: > > Hi Scott, > > > > The discussion has been moved to "freebsd-arch@freebsd.org". Please only > > reply there next time. > > > > On Wednesday 26 September 2007, Scott Long wrote: > >> Hans Petter Selasky wrote: > >>> Hi, > >>> > >>> Please keep me CC'ed, hence I'm not on all these lists. > >>> > >>> In the kernel we currently have two different data backstores: > >>> > >>> struct mbuf > >>> > >>> and > >>> > >>> struct buf > >>> > >>> These two backstores serve two different device types. "mbufs" are for > >>> network devices and "buf" is for disk devices. > >>> > >>> Problem: > >>> > >>> The current backstores are loaded into DMA by using the BUS-DMA > >>> framework. This appears not to be too fast according to Kip Macy. See: > >>> > >>> http://perforce.freebsd.org/chv.cgi?CH=126455 > >> > >> Busdma isn't fast enough for 1Gb and 10Gb network drivers that are > >> trying to max out their packet rates. It's still fine for storage > >> drivers and other slow/medium speed device drivers, like USB and > >> Firewire. I am working on techniques to make the API easier to use > >> and the implementation fast enough for the aforementioned devices. > > > > That's great! > > Well, the point is that I'm not sure why you're so worried about > performance issues with USB and busdma. Do you have any test data that > shows that it's a problem? It is a problem on embedded devices. Typically not for an ordinary PC user. > > >>> Some ideas I have: > >>> > >>> When a buffer is out out of range for a hardware device and a data-copy > >>> is needed I want to simply copy that data in smaller parts to/from a > >>> pre-allocated bounce buffer. I want to avoid allocating this buffer > >>> when "bus_dmamap_load()" is called. > >> > >> I think you've missed the point of having architecture portable drivers. > >> John-Mark describes this further. > > > > I use the bus_dma framework to allocate and sync all DMA memory, and I > > assume that is correct. > > That is one of the uses of busdma, yes. The other is to handle buffers > that have been allocated elsewhere in the system. Ok. > > >> It also makes little sense to push > >> the responsibility for handling bounce buffers out of a central > >> subsystem and back into every driver. > > > > I'm thinking about putting some wrappers around the "bus_dmamap_load()" > > function like: > > > > void usbd_rx_buf_load(struct usbd_xfer *xfer, void *buf, > > uint32_t framebuffer_offset, uint32_t framebuffer_index, uint32_t len); > > > > void usbd_tx_buf_load(struct usbd_xfer *xfer, void *buf, > > uint32_t framebuffer_offset, uint32_t framebuffer_index, uint32_t len); > > > > But I haven't figured out all the details yet. The "usbd_xxx_load()" > > functions should automagically figure out what is best to do and it won't > > be more than a few lines of code. > > Can you describe what these two wrappers are supposed to do? Are you > expecting bus_dmamap_load() to operate synchronously? I will come back to this question after the weekend, if you don't mind. Right now I'm in a hurry. --HPS