svn commit: r212061 - head/sys/dev/bge

John Baldwin jhb at freebsd.org
Tue Aug 31 17:51:03 UTC 2010


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


More information about the svn-src-all mailing list