On Tuesday, August 31, 2010 1:33:48 pm Pyun YongHyeon wrote: > Author: yongari > Date: Tue Aug 31 17:33:48 2010 > New Revision: 212061 > URL: http://svn.freebsd.org/changeset/base/212061 > > Log: > Split common parent DMA tag into ring DMA tag and TX/RX mbuf DMA > tag. All controllers that are not BCM5755 or higher have 4GB > boundary DMA bug. Previously bge(4) used 32bit DMA address to > workaround the bug(r199670). However this caused the use of bounce > buffers such that it resulted in poor performance for systems which > have more than 4GB memory. Because bus_dma(9) honors boundary > restriction requirement of DMA tag for dynamic buffers, having a > separate TX/RX mbuf DMA tag will greatly reduce the possibility of > using bounce buffers. For DMA buffers allocated with > bus_dmamem_alloc(9), now bge(4) explicitly checks whether the > requested memory region crossed the boundary or not. > With this change, only the DMA buffer that crossed the boundary > will use 32bit DMA address. Other DMA buffers are not affected as > separate DMA tag is created for each DMA buffer. > Even if 32bit DMA address space is used for a buffer, the chance to > use bounce buffer is still very low as the size of buffer is small. > This change should eliminate most usage of bounce buffers on > systems that have more than 4GB memory. > > More correct fix would be teaching bus_dma(9) to honor boundary > restriction for buffers created with bus_dmamem_alloc(9) but it > seems that is not easy. > > While I'm here cleanup bge_dma_map_addr() and remove unnecessary > member variables in bge_dmamap_arg structure.
Keep in mind the PAE case where you cannot effectively specify a 4GB boundary. I used a 2GB boundary for twa(4) in the PAE case to deal with the boundary issue. Probably though, bus_dma should just always enforce a 4GB boundary, at least on x86. -- John Baldwin _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"