RE: [PATCH V3 1/5] RDMA/core: Transport-independent access flags

Steve Wise
2015-07-14T20:10:56Z

> -----Original Message-----
> From: 'Christoph Hellwig' [mailto:hch@infradead.org]
> Sent: Tuesday, July 14, 2015 2:55 PM
> To: Steve Wise
> Cc: 'Jason Gunthorpe'; 'Sagi Grimberg'; 'Steve Wise'; 'Tom Talpey'; 'Doug Ledford'; 'Christoph Hellwig'; sagig@mellanox.com;
> ogerlitz@mellanox.com; roid@mellanox.com; linux-rdma@vger.kernel.org; eli@mellanox.com; target-devel@vger.kernel.org; linux-
> nfs@vger.kernel.org; trond.myklebust@primarydata.com; bfields@fieldses.org; 'Oren Duer'
> Subject: Re: [PATCH V3 1/5] RDMA/core: Transport-independent access flags
>
> 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
>

Perhaps I missed some of the discussion on all this, but what is the point of #1?

Are these 4 steps intended to be (bisectable) steps / commits with the goal of removing ib_get_dma_mr()? If so I still don't get
#1.

Steve.