From owner-freebsd-scsi@FreeBSD.ORG Thu Sep 27 01:13:52 2007 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE3ED16A418; Thu, 27 Sep 2007 01:13:52 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 7BF9B13C48A; Thu, 27 Sep 2007 01:13:52 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l8R1DPix065986; Wed, 26 Sep 2007 19:13:26 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <46FB03B1.6020100@samsco.org> Date: Wed, 26 Sep 2007 19:13:21 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 MIME-Version: 1.0 To: Hans Petter Selasky References: <200709260131.49156.hselasky@c2i.net> <46FA9C04.9060603@samsco.org> <200709262157.02712.hselasky@c2i.net> In-Reply-To: <200709262157.02712.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Wed, 26 Sep 2007 19:13:26 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org 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-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2007 01:13:53 -0000 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? >>> 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. >> 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? Scott