[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250526154133.GF9786@nvidia.com>
Date: Mon, 26 May 2025 12:41:33 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Abhijit Gangurde <abhijit.gangurde@....com>
Cc: shannon.nelson@....com, brett.creeley@....com, davem@...emloft.net,
edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
corbet@....net, leon@...nel.org, andrew+netdev@...n.ch,
allen.hubbe@....com, nikhil.agarwal@....com,
linux-rdma@...r.kernel.org, netdev@...r.kernel.org,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 00/14] Introduce AMD Pensando RDMA driver
On Mon, May 26, 2025 at 10:19:38AM -0300, Jason Gunthorpe wrote:
> > > @@ -1454,11 +1466,15 @@ static int ionic_destroy_cq(struct ib_cq *ibcq, struct ib_udata *udata)
> > > static bool pd_local_privileged(struct ib_pd *pd)
> > > {
> > > + /* That isn't how it works, only the lkey get_dma_mr() returns is
> > > + special and must be used on any WRs that require it. WRs refering to any
> > > + other lkeys must behave normally. */
> > > return !pd->uobject;
> > > }
I was thinking about this some more, probably the call to get_dma_mr()
should set a flag in the pd struct (you need a pds_pd struct) which
indicates that the IONIC_DMA_LKEY is enabled on that PD. Then all
QPs/etc created against the PD should allow using it.
Checking a uobject here is just a little weird.
Jason
Powered by blists - more mailing lists