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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 9 May 2014 15:46:14 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Neil Horman' <>
CC:	"" <>,
	"" <>
Subject: RE: [RFC PATCH] net: Provide linear backoff mechanism for
 constrained resources at the driver

From: Neil Horman []
> 2 Things:
> 1) Need is really a strong term here.  The penalty for failing a dma mapping is
> to drop the frame.  Thats not unacceptible in many use cases.

Indeed, but dropping an ethernet frame will be recovered by the higher layers.
While not ideal, it is a 'last resort' action.
Note that I'm not suggesting that your deferred retry of the transmit isn't
a good idea, just that it is probably papering over the cracks.

> 2) It seems to me that global constraint here implies a static, well known
> number.  While its true we can interrogate an iommu, and compare its mapping
> size to the ring size of all the NICS/devices on a system to see if we're likely
> to exceed the iommu space available, we shouldn't do that.  If a given NIC
> doesn't produce much traffic, its ring sizes aren't relevant to the computation.

An idle NIC will be using a lot of iommu entries for its receive buffers.

> We're not trying to address a static allocation scheme here.  If a system boots,
> it implies that all the recive rings on all the devices were able to reserve the
> amount of space they needed in the iommu (as you note earlier, they populate
> their rings on init, effectively doing a iommu reservation).  The problem we're
> addressing is the periodic lack of space that arises from temporary exhaustion
> of iommu space under heavy I/O loads.  We won't know if that happens, until it
> happens, and we can't just allocate for the worst case, because then we're sure
> to run out of space as devices scale up.  Sharing is the way to do this whenever
> possible.

Do you have any data for which drivers have active iommu entries when an
allocate fails?

I can imagine systems where almost all the iommu entries are being used
for ethernet rx buffers, and everything else is fighting for the last
few entries.


To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists