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.
(2) now ULD can check for IB_DEVICE_LOCAL_DMA_LKEY and use local_dma_lkey
in that case, or will have to perform a per-IO MR with LOCAL and
REMOTE flags if not
(3) remove insecure remote uses of ib_get_dma_mr from ULDs
(4) remove ib_get_dma_mr from the public API
This should help to sort out the lkey side of the memory registrations,
and isn't too hard. For rkeys I'd love to go with something like Sagis
proposal as a first step, and then we can see if we can refine it in
another iteration.
Given that we might not be able to do the above for the next merge
window add your iWarp transport heck for now, at least we'll have a
clear plan to remove it.
--
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
