Date: Tue, 31 Aug 2010 17:33:48 +0000 (UTC) From: Pyun YongHyeon <yongari@FreeBSD.org> To: cvs-src-old@freebsd.org Subject: cvs commit: src/sys/dev/bge if_bge.c if_bgereg.h Message-ID: <201008311734.o7VHYWnp012875@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
yongari 2010-08-31 17:33:48 UTC
FreeBSD src repository
Modified files:
sys/dev/bge if_bge.c if_bgereg.h
Log:
SVN rev 212061 on 2010-08-31 17:33:48Z by yongari
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.
Tested by: marcel
Revision Changes Path
1.297 +145 -238 src/sys/dev/bge/if_bge.c
1.102 +7 -5 src/sys/dev/bge/if_bgereg.h
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201008311734.o7VHYWnp012875>