On Wed, 06 Dec 2006 16:54:18 -0800 (PST) David Miller <[EMAIL PROTECTED]> wrote:
> From: Stephen Hemminger <[EMAIL PROTECTED]> > Date: Wed, 6 Dec 2006 10:16:44 -0800 > > > I think it is really only an issue for drivers that turn on HIGH_DMA > > and have limited mask values. The majority of drivers either only handle > > 32 bit (!HIGH_DMA) or do full 64 bit mapping. I don't know the details > > of how we manage IOMMU, but doesn't mapping always work for those drivers. > > > > That just leaves devices with odd size mask values that need to be > > handle mapping errors. > > Not true. > > On platforms such as sparc64 the IOMMU is used for all DMA mappings, > no matter what, because only IOMMU based mappings can do prefetching > and write-combining in the PCI controller. > > The problem with just silently dropping packets that can't get DMA > mapped is that you're going to drop a very large sequence of these > while the IOMMU is out of space, and that to me looks like a bad > quality of implementation decision. > > The IOMMU layer really needs a way to callback the driver to tell it > when space is available, or something similar. > > FWIW, Solaris handles this by blocking when the IOMMU is out of space > since under Solaris even interrupt contexts can block (via interrupt > threads). > - > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html The more robust way would be to stop the queue (like flow control) and return busy. You would need a timer though to handle the case where some disk i/o stole all the mappings and then network device flow blocked. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
