On 7/14/2015 4:29 PM, Jason Gunthorpe wrote:
On Tue, Jul 14, 2015 at 12:55:11PM -0700, 'Christoph Hellwig' wrote:
On Tue, Jul 14, 2015 at 02:32:31PM -0500, Steve Wise wrote:
You mean "should not", yea?
Ok. I'll check for iWARP. But don't tell me to remove the transport-specific hacks in this series when I post it! ;)
Just curious if there are any holes in this little scheme to deal with
the lkey mess:
(1) make sure all drivers that currently do not set
IB_DEVICE_LOCAL_DMA_LKEY but which can safely use ib_get_dma_mr
call it underneath at device setup time, and tear it down before
removal.
Yes, I'd like this.
local_dma_lkey appears to be global, it works with any PD.
Only if it's supported, right? There's an attribute that a provider uses
to expose it. For example, I would not expect a virtualized provider to
be able to support this.
ib_get_dma_mr is tied to a PD, so it cannot replace local_dma_lkey at
the struct device level.
Correct, and by design, in fact. In most implementations, a different
token is returned for each call, in fact.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
