netdev - RE: [PATCH] jme: Fix DMA unmap warning

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:	Thu, 8 May 2014 11:16:21 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Neil Horman' <nhorman@...driver.com>
CC:	David Miller <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"cooldavid@...ldavid.org" <cooldavid@...ldavid.org>
Subject: RE: [PATCH] jme: Fix DMA unmap warning

From: Neil Horman
> On Thu, May 08, 2014 at 09:02:04AM +0000, David Laight wrote:
> > 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 don't think that will work (or more specifically, it won't work in a wide
> enough range of cases).  We can't reasonably predict how many devices will need
> to use dma and how much space each device will need.  A common desktop system
> will likely have no issue with reserving enough room for each nic, but a system
> with 5+ nics/infiniband/fcoe on board is going to have a lot more trouble.  And
> if you happen to be using swiotlb for whatever reason, you may not be able to
> reserve enough space at all.

Which is why I suggested a 'claw back' mechanism to reclaim some entries.
NFI how it could be made to work though.

> What we really need is just a way for the dma_* api to put backpressure on
> callers for a very brief period of time.  Thats why I was thinking something
> involving completion interupts or unmapping events.

A problem I see is that a large number of iommu entries can get used
by network drivers for receive buffers.
If the system is short of iommu entries, then the number of rx buffers
will need to be limited.

Maybe there should be 'low' and 'high' priority requests?
Ethernet drivers using low priority requests for most requests
- except the first few rx buffers, and the first tx buffer?

Your wakeup mechanism would still be needed.

	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