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  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:	Thu, 8 May 2014 09:02:04 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Neil Horman' <>,
	David Miller <>
CC:	"" <>,
	"" <>
Subject: RE: [PATCH] jme: Fix DMA unmap warning

From: Neil Horman
> Perhaps a solution is a signalling mechanism tied to completion interrupts?
> I.e. a mapping failure gets reported to the stack, which causes the
> correspondnig queue to be stopped, until such time a the driver signals a safe
> restart by the reception of a tx completion interrupt?  I'm actually tinkering
> right now with a mechanism that provides guidance to the stack as to how many
> dma descriptors are available in a given net_device that might come in handy

Is there any mileage in the driver pre-allocating a block of iommu entries
and then allocating them to the tx and rx buffers itself?
This might need some 'claw back' mechanism to get 'fair' (ok working)
allocations when there aren't enough entries for all the drivers.

I remember some old systems where the cost of setting up the iommu
entries was such that the breakeven point for copying data was
measured as about 1k bytes. I've no idea what it is for these systems.


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