Linux RDMA and InfiniBand development
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: haris iqbal <haris.phnx@gmail.com>
Cc: "lizhijian@fujitsu.com" <lizhijian@fujitsu.com>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	"bvanassche@acm.org" <bvanassche@acm.org>,
	"leon@kernel.org" <leon@kernel.org>,
	"haris.iqbal@ionos.com" <haris.iqbal@ionos.com>,
	"jinpu.wang@ionos.com" <jinpu.wang@ionos.com>,
	"aleksei.marov@ionos.com" <aleksei.marov@ionos.com>,
	"rpearsonhpe@gmail.com" <rpearsonhpe@gmail.com>
Subject: Re: [PATCH] RDMA/rxe: Split rxe_invalidate_mr into local and remote versions
Date: Fri, 24 Jun 2022 20:27:45 -0300	[thread overview]
Message-ID: <20220624232745.GF23621@ziepe.ca> (raw)
In-Reply-To: <CAE_WKMy-rGgh_6_=OY_77pXNmV73tmww18eb4+XLpp_DtyASdA@mail.gmail.com>

On Mon, Jun 13, 2022 at 04:20:36PM +0200, haris iqbal wrote:
> > On 09/06/2022 20:03, Md Haris Iqbal wrote:
> > > Currently rxe_invalidate_mr does invalidate for both local ops, and remote
> > > ones. This means that MR being invalidated is compared with rkey for both,
> > > which is incorrect. For local invalidate, comparison should happen with
> > > lkey,
> > Just checked that IBTA SPEC ”10.6.5“ says that consumer *must* L_Key, R_Key ...
> > Not sure whether we should concern these.

I agree, 10.6.5 is quite clear that the ULP must present all of the
three options and the HCA can choose any of them.

So, rxe cannot have a bug if it always uses the rkey ?

> There are multiple things to consider here.. Since the wr for
> invalidate can have only one invalidate_rkey, there is probably no way
> to send lkey and rkey both as mentioned in the spec.

In general what this reflects is that in Linux that we don't really
completely support the optional idea in IBA that the HCA can have a
different key space for l and r keys.

> One way to make this work (mlx does this maybe?) is to always make
> rkey and lkey same and NOT make this dependent on access. Whether an
> MR is open for RDMA operations or not can be checked through the
> access permissions. I am guessing this is how it was working before.

Yes, no driver in Linux suports a disjoint key space.

So, I'm revoking my 'this makes sense to me' - the commit message does
not explain how the IBA requires the use of a lkey for a local
invalidate.

Jason

  reply	other threads:[~2022-06-24 23:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-09 12:03 [PATCH] RDMA/rxe: Split rxe_invalidate_mr into local and remote versions Md Haris Iqbal
2022-06-09 15:28 ` haris iqbal
2022-06-13  2:20 ` lizhijian
2022-06-13 14:20   ` haris iqbal
2022-06-24 23:27     ` Jason Gunthorpe [this message]
2022-06-28 16:21       ` haris iqbal
2022-06-28 16:34         ` Jason Gunthorpe
2022-06-28 16:46           ` haris iqbal
2022-06-28 16:50             ` Jason Gunthorpe
2022-06-28 17:05               ` haris iqbal
2022-06-28 20:04                 ` Bob Pearson
2022-06-29 12:56                   ` haris iqbal
2022-06-29 15:04                     ` Pearson, Robert B
2022-06-29 15:30                       ` haris iqbal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220624232745.GF23621@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=aleksei.marov@ionos.com \
    --cc=bvanassche@acm.org \
    --cc=haris.iqbal@ionos.com \
    --cc=haris.phnx@gmail.com \
    --cc=jinpu.wang@ionos.com \
    --cc=leon@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=lizhijian@fujitsu.com \
    --cc=rpearsonhpe@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox