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

Jason Gunthorpe
2015-07-14T20:59:25Z

On Tue, Jul 14, 2015 at 03:54:15PM -0500, Steve Wise wrote:
> > > I'm not seeing the benefit of adding pd->local_dma_lkey?
> > > pd->device->local_dma_lkey is there for core and ULP use, and we
> > > could have old drivers that don't currently have support for
> > > local_dma_lkey allocate their own private pd/dma_mr (via their
> > > private functions for doing this) with only LOCAL_WRITE access
> > > flags, and export that lkey as the device->local_dma_lkey. Wouldn't
> > > that be simpler?
> >
> > It would be, but AFAIK that can't work?
> >
> > My understanding is if you create a QP against a PD then only lkeys
> > and rkeys (and local_dma_rkey) created against that PD are valid for
> > use with that QP.
> >
> > I can't use an lkey from a PD not associated with the QP.
> >
> > Am I wrong on this?
>
> Kernel users can use the local_dma_lkey for all lkey IO on all QPs
> (ignoring the iwarp read issue). Look at sc_dma_lkey in the NFSRDMA
> server.

Read the exchange again?

You asked this:

> > > could have old drivers that don't currently have support for
> > > local_dma_lkey allocate their own private pd/dma_mr (via their

The answer to why that doesn't work is: In the generic case of old
drivers every PD has a different local_dma_lkey value.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in