On Wed, 06 Dec 2006 23:24:59 -0800 (PST) David Miller <[EMAIL PROTECTED]> wrote:
> From: "Amit S. Kale" <[EMAIL PROTECTED]> > Date: Thu, 7 Dec 2006 11:55:22 +0530 > > > We can let a driver handle dma mapping errors using these-> > > > > 1.Reduce the size of a receive ring. This will free some possibly remapped > > memory, reducing pressure on iommu. We also need to printk a message so > > that > > a user knows the reason why receive ring was shrunk. Growing it when iommu > > pressure goes down will result in a ping-pong. > > 2. Force processing of receive and transmit ring. This will ensure that the > > buffers processed by hardware are freed, reducing iommu pressure. > > > > 3. If we need to do (1) and (2) a predefined number of times (say 20), stop > > the queue. Stopping the queue in general will cause a ping-pong, so it > > should > > be avoided as far as possible. > > This scheme assumes the networking card is the culprit. In many > workloads it will not be and these efforts will be in vain and perhaps > even make the situation worse. There's not reason to run the RX and > TX queues, and even shrink them, when the FC controller has most of > the IOMMU entires tied up. > > That's why users needs to queue up and get feedback when IOMMU space > is made available. Looking at other subsystems, the disk code seems to return I/O errors if dma mapping fails. Perhaps this discussion needs to move off to lkml or the platform lists. - 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