From owner-freebsd-net@FreeBSD.ORG Wed Sep 26 19:56:57 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A11716A419; Wed, 26 Sep 2007 19:56:57 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id 7ADDF13C4A6; Wed, 26 Sep 2007 19:56:56 +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 mailfe04.swip.net (CommuniGate Pro SMTP 5.1.10) with ESMTPA id 626638699; Wed, 26 Sep 2007 21:56:43 +0200 From: Hans Petter Selasky To: Scott Long Date: Wed, 26 Sep 2007 21:57:00 +0200 User-Agent: KMail/1.9.7 References: <200709260131.49156.hselasky@c2i.net> <46FA9C04.9060603@samsco.org> In-Reply-To: <46FA9C04.9060603@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200709262157.02712.hselasky@c2i.net> Cc: freebsd-scsi@freebsd.org, freebsd-arch@freebsd.org, freebsd-usb@freebsd.org, freebsd-net@freebsd.org Subject: Re: Request for feedback on common data backstore in the kernel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Sep 2007 19:56:57 -0000 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! > > > 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. > 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. --HPS