Date: Fri, 27 Jun 2003 16:58:35 -0400 (EDT) From: Andrew Gallatin <gallatin@cs.duke.edu> To: Scott Long <scott_long@btc.adaptec.com> Cc: freebsd-arch@freebsd.org Subject: Re: API change for bus_dma Message-ID: <16124.45051.919899.414795@grasshopper.cs.duke.edu> In-Reply-To: <3EFCAC7A.6060305@btc.adaptec.com> References: <3EF3C12F.9060303@btc.adaptec.com> <16124.39930.142492.356163@grasshopper.cs.duke.edu> <3EFC9F2D.6020908@btc.adaptec.com> <16124.43999.333761.397624@grasshopper.cs.duke.edu> <3EFCAC7A.6060305@btc.adaptec.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Scott Long writes: > > I'm not familiar with Solaris DDI. bus_dmamem_alloc() is guaranteed to > give you contiguous memory that doesn't require bouncing (or ENOMEM if > that's not possible). I can't imagine what DDI_DMA_STREAMING is. Most sparc's have 2 different sorts of DMA modes. One is cache coherent (aka DDI_DMA_CONSISTENT) -- this is what we all know and love from PC, alphas, macs, etc. The other mode (DDI_DMA_STREAMING) allows non cache coherent DMA. This requires you to call ddi_dma_sync() between your last touch of the data and you starting a DMA read from a device. And vice-versa for a DMA write. The reason people use DDI_DMA_STREAMING is because coherent DMA bandwith tends to be abysmal on most sparcs. Using DDI_DMA_STREAMING upgrades the bandwith from abysmal to just bad. Here are some examples: For u80, UltraSPARC II, using chip "Psycho", 98 MBytes/s consistent vs. 150 MBytes/s streaming. For sunfire, UltraSPARC III, using chip "Schizo", 70 MBytes/s consistent vs. 173 MBytes/s streaming. (compare to 450MB/sec for most intel 64-bit/66MHz PCI slots).. Drew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16124.45051.919899.414795>