netdev - RE: [RFC PATCH] net: Provide linear backoff mechanism for constrained resources at the driver

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] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 9 May 2014 08:55:10 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Neil Horman' <nhorman@...driver.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:	"davem@...emloft.net" <davem@...emloft.net>
Subject: RE: [RFC PATCH] net: Provide linear backoff mechanism for
 constrained resources at the driver

From: Neil Horman
> What about something like this?  Its not even compile tested, but let me know
> what you think of the idea.  The reasoning behind it is that transient resources
> like dma address ranges in the iommu or swiotlb have the following attributes
> 
> 1) they are quickly allocated and freed

I'm not sure that is true for iommu entries.
The ones allocated for ethernet receive are effectively permanently allocated.

Imagine a system with 512 iommu entries.
An ethernet driver allocates 128 RX ring entries using one iommu entry each.
There are now no iommu entries left for anything else.
That system will only work if the ethernet driver reduces the number of
active rx buffers.

It is also possible (but less likely) that ethernet transmit will
use so many iommu entries that none are left for more important things.
The network will work with only one active transmit, but you may
have to do disc and/or usb transfers even when resource limited.

	David

--
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