Re: [PATCH] RDMA/rxe: For invalidate compare keys according to the MR access

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 06, 2022 at 05:41:08AM +0200, haris iqbal wrote:
> On Tue, Jul 5, 2022 at 4:00 PM Jason Gunthorpe <jgg@xxxxxxxx> wrote:
> >
> > On Tue, Jul 05, 2022 at 11:28:59AM +0200, haris iqbal wrote:
> > > On Wed, Jun 29, 2022 at 8:48 PM Pearson, Robert B
> > > <robert.pearson2@xxxxxxx> wrote:
> > > >
> > > > > > > If the rkey's and lkeys are always the same why do we store them twice in the mr ?
> > > > > >
> > > > > > They are not always the same currently. If you request remote access they are the same if you don't rkey is set to zero.
> > > > > > You could, of course, check both the keys and the access bits but that is not the way it is written currently.
> > > >
> > > > > Storing the rkey instead of checking the flags seems like a weird obfuscation to me..
> > > >
> > > > > Jason
> > > >
> > > > One always has the choice to always just use the lkey and check the flags. But referring the rkey just uses one memory reference 😊
> > >
> > > Have we reached a consensus here as to how to solve this?
> > >
> > > This (and the issue created by dual map) has basically caused a
> > > regression in RTRS since the 5.15. And we would appreciate it a lot if
> > > the fix goes in and is backported.
> >
> > I think your patch is close, it should just be tweaked a bit.
> 
> I couldn't conclude from the conversation above what that tweak should
> be, if a conclusion has been reached. If not, then I'll wait.

The 'rkey' input can be an lkey or rkey, and in rxe the lkey or rkey
have the same value, including the variant bits.

So, don't check based on the flags, if the rkey is not 0 check it,
otherwise check the lkey

Since we already did a lookup on the non-varient bits to get this far,
the check's only purpose is to confirm that the wqe has the correct
variant bits.

Jason



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux