netdev - Re: network devices don't handle pci_dma_mapping

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 7 Dec 2006 12:07:52 -0800
From:	Stephen Hemminger <shemminger@...l.org>
To:	David Miller <davem@...emloft.net>
Cc:	amitkale@...syssoft.com, muli@...ibm.com, jeff@...zik.org,
	amitkale@...xen.com, netdev@...r.kernel.org, brazilnut@...ibm.com,
	netxenproj@...syssoft.com, rob@...xen.com, romieu@...zoreil.com,
	sanjeev@...xen.com, wendyx@...ibm.com
Subject: Re: network devices don't handle pci_dma_mapping_error()'s

On Wed, 06 Dec 2006 23:24:59 -0800 (PST)
David Miller <davem@...emloft.net> wrote:

> From: "Amit S. Kale" <amitkale@...syssoft.com>
> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html