linux-rdma.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] RDMA/rxe: Split rxe_invalidate_mr into local and remote versions
@ 2022-06-09 12:03 Md Haris Iqbal
  2022-06-09 15:28 ` haris iqbal
  2022-06-13  2:20 ` lizhijian
  0 siblings, 2 replies; 14+ messages in thread
From: Md Haris Iqbal @ 2022-06-09 12:03 UTC (permalink / raw)
  To: linux-rdma
  Cc: bvanassche, leon, jgg, haris.iqbal, jinpu.wang, aleksei.marov,
	Md Haris Iqbal, rpearsonhpe

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, and for the remote one, it should happen with rkey.

This commit splits the rxe_invalidate_mr into local and remote versions.
Each of them does comparison the right way as described above (with lkey
for local, and rkey for remote).

Fixes: 3902b429ca14 ("RDMA/rxe: Implement invalidate MW operations")
Cc: rpearsonhpe@gmail.com
Signed-off-by: Md Haris Iqbal <haris.phnx@gmail.com>
---
 drivers/infiniband/sw/rxe/rxe_loc.h  |  3 +-
 drivers/infiniband/sw/rxe/rxe_mr.c   | 59 +++++++++++++++++++++-------
 drivers/infiniband/sw/rxe/rxe_req.c  |  2 +-
 drivers/infiniband/sw/rxe/rxe_resp.c |  2 +-
 4 files changed, 49 insertions(+), 17 deletions(-)

diff --git a/drivers/infiniband/sw/rxe/rxe_loc.h b/drivers/infiniband/sw/rxe/rxe_loc.h
index 0e022ae1b8a5..4da57abbbc8c 100644
--- a/drivers/infiniband/sw/rxe/rxe_loc.h
+++ b/drivers/infiniband/sw/rxe/rxe_loc.h
@@ -77,7 +77,8 @@ struct rxe_mr *lookup_mr(struct rxe_pd *pd, int access, u32 key,
 			 enum rxe_mr_lookup_type type);
 int mr_check_range(struct rxe_mr *mr, u64 iova, size_t length);
 int advance_dma_data(struct rxe_dma_info *dma, unsigned int length);
-int rxe_invalidate_mr(struct rxe_qp *qp, u32 rkey);
+int rxe_invalidate_mr_local(struct rxe_qp *qp, u32 lkey);
+int rxe_invalidate_mr_remote(struct rxe_qp *qp, u32 rkey);
 int rxe_reg_fast_mr(struct rxe_qp *qp, struct rxe_send_wqe *wqe);
 int rxe_mr_set_page(struct ib_mr *ibmr, u64 addr);
 int rxe_dereg_mr(struct ib_mr *ibmr, struct ib_udata *udata);
diff --git a/drivers/infiniband/sw/rxe/rxe_mr.c b/drivers/infiniband/sw/rxe/rxe_mr.c
index fc3942e04a1f..1c7179dd92eb 100644
--- a/drivers/infiniband/sw/rxe/rxe_mr.c
+++ b/drivers/infiniband/sw/rxe/rxe_mr.c
@@ -576,41 +576,72 @@ struct rxe_mr *lookup_mr(struct rxe_pd *pd, int access, u32 key,
 	return mr;
 }
 
-int rxe_invalidate_mr(struct rxe_qp *qp, u32 rkey)
+static int rxe_invalidate_mr(struct rxe_mr *mr)
+{
+	if (atomic_read(&mr->num_mw) > 0) {
+		pr_warn("%s: Attempt to invalidate an MR while bound to MWs\n",
+			__func__);
+		return -EINVAL;
+	}
+
+	if (unlikely(mr->type != IB_MR_TYPE_MEM_REG)) {
+		pr_warn("%s: mr->type (%d) is wrong type\n", __func__, mr->type);
+		return -EINVAL;
+	}
+
+	mr->state = RXE_MR_STATE_FREE;
+	return 0;
+}
+
+int rxe_invalidate_mr_local(struct rxe_qp *qp, u32 lkey)
 {
 	struct rxe_dev *rxe = to_rdev(qp->ibqp.device);
 	struct rxe_mr *mr;
 	int ret;
 
-	mr = rxe_pool_get_index(&rxe->mr_pool, rkey >> 8);
+	mr = rxe_pool_get_index(&rxe->mr_pool, lkey >> 8);
 	if (!mr) {
-		pr_err("%s: No MR for rkey %#x\n", __func__, rkey);
+		pr_err("%s: No MR for lkey %#x\n", __func__, lkey);
 		ret = -EINVAL;
 		goto err;
 	}
 
-	if (rkey != mr->rkey) {
-		pr_err("%s: rkey (%#x) doesn't match mr->rkey (%#x)\n",
-			__func__, rkey, mr->rkey);
+	if (lkey != mr->lkey) {
+		pr_err("%s: lkey (%#x) doesn't match mr->lkey (%#x)\n",
+			__func__, lkey, mr->lkey);
 		ret = -EINVAL;
 		goto err_drop_ref;
 	}
 
-	if (atomic_read(&mr->num_mw) > 0) {
-		pr_warn("%s: Attempt to invalidate an MR while bound to MWs\n",
-			__func__);
+	ret = rxe_invalidate_mr(mr);
+
+err_drop_ref:
+	rxe_put(mr);
+err:
+	return ret;
+}
+
+int rxe_invalidate_mr_remote(struct rxe_qp *qp, u32 rkey)
+{
+	struct rxe_dev *rxe = to_rdev(qp->ibqp.device);
+	struct rxe_mr *mr;
+	int ret;
+
+	mr = rxe_pool_get_index(&rxe->mr_pool, rkey >> 8);
+	if (!mr) {
+		pr_err("%s: No MR for rkey %#x\n", __func__, rkey);
 		ret = -EINVAL;
-		goto err_drop_ref;
+		goto err;
 	}
 
-	if (unlikely(mr->type != IB_MR_TYPE_MEM_REG)) {
-		pr_warn("%s: mr->type (%d) is wrong type\n", __func__, mr->type);
+	if (rkey != mr->rkey) {
+		pr_err("%s: rkey (%#x) doesn't match mr->rkey (%#x)\n",
+			__func__, rkey, mr->rkey);
 		ret = -EINVAL;
 		goto err_drop_ref;
 	}
 
-	mr->state = RXE_MR_STATE_FREE;
-	ret = 0;
+	ret = rxe_invalidate_mr(mr);
 
 err_drop_ref:
 	rxe_put(mr);
diff --git a/drivers/infiniband/sw/rxe/rxe_req.c b/drivers/infiniband/sw/rxe/rxe_req.c
index 9d98237389cf..e7dd9738a255 100644
--- a/drivers/infiniband/sw/rxe/rxe_req.c
+++ b/drivers/infiniband/sw/rxe/rxe_req.c
@@ -550,7 +550,7 @@ static int rxe_do_local_ops(struct rxe_qp *qp, struct rxe_send_wqe *wqe)
 		if (rkey_is_mw(rkey))
 			ret = rxe_invalidate_mw(qp, rkey);
 		else
-			ret = rxe_invalidate_mr(qp, rkey);
+			ret = rxe_invalidate_mr_local(qp, rkey);
 
 		if (unlikely(ret)) {
 			wqe->status = IB_WC_LOC_QP_OP_ERR;
diff --git a/drivers/infiniband/sw/rxe/rxe_resp.c b/drivers/infiniband/sw/rxe/rxe_resp.c
index f4f6ee5d81fe..01411280cd73 100644
--- a/drivers/infiniband/sw/rxe/rxe_resp.c
+++ b/drivers/infiniband/sw/rxe/rxe_resp.c
@@ -818,7 +818,7 @@ static int invalidate_rkey(struct rxe_qp *qp, u32 rkey)
 	if (rkey_is_mw(rkey))
 		return rxe_invalidate_mw(qp, rkey);
 	else
-		return rxe_invalidate_mr(qp, rkey);
+		return rxe_invalidate_mr_remote(qp, rkey);
 }
 
 /* Executes a new request. A retried request never reach that function (send
-- 
2.25.1


^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: [PATCH] RDMA/rxe: Split rxe_invalidate_mr into local and remote versions
  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
  1 sibling, 0 replies; 14+ messages in thread
From: haris iqbal @ 2022-06-09 15:28 UTC (permalink / raw)
  To: linux-rdma
  Cc: bvanassche, Leon Romanovsky, jgg, haris.iqbal, jinpu.wang,
	aleksei.marov, rpearsonhpe, zyjzyj2000

On Thu, Jun 9, 2022 at 2:03 PM Md Haris Iqbal <haris.phnx@gmail.com> 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, and for the remote one, it should happen with rkey.
>
> This commit splits the rxe_invalidate_mr into local and remote versions.
> Each of them does comparison the right way as described above (with lkey
> for local, and rkey for remote).
>
> Fixes: 3902b429ca14 ("RDMA/rxe: Implement invalidate MW operations")
> Cc: rpearsonhpe@gmail.com
> Signed-off-by: Md Haris Iqbal <haris.phnx@gmail.com>
> ---
>  drivers/infiniband/sw/rxe/rxe_loc.h  |  3 +-
>  drivers/infiniband/sw/rxe/rxe_mr.c   | 59 +++++++++++++++++++++-------
>  drivers/infiniband/sw/rxe/rxe_req.c  |  2 +-
>  drivers/infiniband/sw/rxe/rxe_resp.c |  2 +-
>  4 files changed, 49 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/infiniband/sw/rxe/rxe_loc.h b/drivers/infiniband/sw/rxe/rxe_loc.h
> index 0e022ae1b8a5..4da57abbbc8c 100644
> --- a/drivers/infiniband/sw/rxe/rxe_loc.h
> +++ b/drivers/infiniband/sw/rxe/rxe_loc.h
> @@ -77,7 +77,8 @@ struct rxe_mr *lookup_mr(struct rxe_pd *pd, int access, u32 key,
>                          enum rxe_mr_lookup_type type);
>  int mr_check_range(struct rxe_mr *mr, u64 iova, size_t length);
>  int advance_dma_data(struct rxe_dma_info *dma, unsigned int length);
> -int rxe_invalidate_mr(struct rxe_qp *qp, u32 rkey);
> +int rxe_invalidate_mr_local(struct rxe_qp *qp, u32 lkey);
> +int rxe_invalidate_mr_remote(struct rxe_qp *qp, u32 rkey);
>  int rxe_reg_fast_mr(struct rxe_qp *qp, struct rxe_send_wqe *wqe);
>  int rxe_mr_set_page(struct ib_mr *ibmr, u64 addr);
>  int rxe_dereg_mr(struct ib_mr *ibmr, struct ib_udata *udata);
> diff --git a/drivers/infiniband/sw/rxe/rxe_mr.c b/drivers/infiniband/sw/rxe/rxe_mr.c
> index fc3942e04a1f..1c7179dd92eb 100644
> --- a/drivers/infiniband/sw/rxe/rxe_mr.c
> +++ b/drivers/infiniband/sw/rxe/rxe_mr.c
> @@ -576,41 +576,72 @@ struct rxe_mr *lookup_mr(struct rxe_pd *pd, int access, u32 key,
>         return mr;
>  }
>
> -int rxe_invalidate_mr(struct rxe_qp *qp, u32 rkey)
> +static int rxe_invalidate_mr(struct rxe_mr *mr)
> +{
> +       if (atomic_read(&mr->num_mw) > 0) {
> +               pr_warn("%s: Attempt to invalidate an MR while bound to MWs\n",
> +                       __func__);
> +               return -EINVAL;
> +       }
> +
> +       if (unlikely(mr->type != IB_MR_TYPE_MEM_REG)) {
> +               pr_warn("%s: mr->type (%d) is wrong type\n", __func__, mr->type);
> +               return -EINVAL;
> +       }
> +
> +       mr->state = RXE_MR_STATE_FREE;
> +       return 0;
> +}
> +
> +int rxe_invalidate_mr_local(struct rxe_qp *qp, u32 lkey)
>  {
>         struct rxe_dev *rxe = to_rdev(qp->ibqp.device);
>         struct rxe_mr *mr;
>         int ret;
>
> -       mr = rxe_pool_get_index(&rxe->mr_pool, rkey >> 8);
> +       mr = rxe_pool_get_index(&rxe->mr_pool, lkey >> 8);
>         if (!mr) {
> -               pr_err("%s: No MR for rkey %#x\n", __func__, rkey);
> +               pr_err("%s: No MR for lkey %#x\n", __func__, lkey);
>                 ret = -EINVAL;
>                 goto err;
>         }
>
> -       if (rkey != mr->rkey) {
> -               pr_err("%s: rkey (%#x) doesn't match mr->rkey (%#x)\n",
> -                       __func__, rkey, mr->rkey);
> +       if (lkey != mr->lkey) {
> +               pr_err("%s: lkey (%#x) doesn't match mr->lkey (%#x)\n",
> +                       __func__, lkey, mr->lkey);
>                 ret = -EINVAL;
>                 goto err_drop_ref;
>         }
>
> -       if (atomic_read(&mr->num_mw) > 0) {
> -               pr_warn("%s: Attempt to invalidate an MR while bound to MWs\n",
> -                       __func__);
> +       ret = rxe_invalidate_mr(mr);
> +
> +err_drop_ref:
> +       rxe_put(mr);
> +err:
> +       return ret;
> +}
> +
> +int rxe_invalidate_mr_remote(struct rxe_qp *qp, u32 rkey)
> +{
> +       struct rxe_dev *rxe = to_rdev(qp->ibqp.device);
> +       struct rxe_mr *mr;
> +       int ret;
> +
> +       mr = rxe_pool_get_index(&rxe->mr_pool, rkey >> 8);
> +       if (!mr) {
> +               pr_err("%s: No MR for rkey %#x\n", __func__, rkey);
>                 ret = -EINVAL;
> -               goto err_drop_ref;
> +               goto err;
>         }
>
> -       if (unlikely(mr->type != IB_MR_TYPE_MEM_REG)) {
> -               pr_warn("%s: mr->type (%d) is wrong type\n", __func__, mr->type);
> +       if (rkey != mr->rkey) {
> +               pr_err("%s: rkey (%#x) doesn't match mr->rkey (%#x)\n",
> +                       __func__, rkey, mr->rkey);
>                 ret = -EINVAL;
>                 goto err_drop_ref;
>         }
>
> -       mr->state = RXE_MR_STATE_FREE;
> -       ret = 0;
> +       ret = rxe_invalidate_mr(mr);
>
>  err_drop_ref:
>         rxe_put(mr);
> diff --git a/drivers/infiniband/sw/rxe/rxe_req.c b/drivers/infiniband/sw/rxe/rxe_req.c
> index 9d98237389cf..e7dd9738a255 100644
> --- a/drivers/infiniband/sw/rxe/rxe_req.c
> +++ b/drivers/infiniband/sw/rxe/rxe_req.c
> @@ -550,7 +550,7 @@ static int rxe_do_local_ops(struct rxe_qp *qp, struct rxe_send_wqe *wqe)
>                 if (rkey_is_mw(rkey))
>                         ret = rxe_invalidate_mw(qp, rkey);
>                 else
> -                       ret = rxe_invalidate_mr(qp, rkey);
> +                       ret = rxe_invalidate_mr_local(qp, rkey);
>
>                 if (unlikely(ret)) {
>                         wqe->status = IB_WC_LOC_QP_OP_ERR;
> diff --git a/drivers/infiniband/sw/rxe/rxe_resp.c b/drivers/infiniband/sw/rxe/rxe_resp.c
> index f4f6ee5d81fe..01411280cd73 100644
> --- a/drivers/infiniband/sw/rxe/rxe_resp.c
> +++ b/drivers/infiniband/sw/rxe/rxe_resp.c
> @@ -818,7 +818,7 @@ static int invalidate_rkey(struct rxe_qp *qp, u32 rkey)
>         if (rkey_is_mw(rkey))
>                 return rxe_invalidate_mw(qp, rkey);
>         else
> -               return rxe_invalidate_mr(qp, rkey);
> +               return rxe_invalidate_mr_remote(qp, rkey);
>  }
>
>  /* Executes a new request. A retried request never reach that function (send
> --
> 2.25.1

Missed adding Zhu. Adding now.

>

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] RDMA/rxe: Split rxe_invalidate_mr into local and remote versions
  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
  1 sibling, 1 reply; 14+ messages in thread
From: lizhijian @ 2022-06-13  2:20 UTC (permalink / raw)
  To: Md Haris Iqbal, linux-rdma
  Cc: bvanassche, leon, jgg, haris.iqbal, jinpu.wang, aleksei.marov,
	rpearsonhpe



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.



> and for the remote one, it should happen with rkey.
>
> This commit splits the rxe_invalidate_mr into local and remote versions.
> Each of them does comparison the right way as described above (with lkey
> for local, and rkey for remote).
>
> Fixes: 3902b429ca14 ("RDMA/rxe: Implement invalidate MW operations")
> Cc: rpearsonhpe@gmail.com
> Signed-off-by: Md Haris Iqbal <haris.phnx@gmail.com>
> ---
>   drivers/infiniband/sw/rxe/rxe_loc.h  |  3 +-
>   drivers/infiniband/sw/rxe/rxe_mr.c   | 59 +++++++++++++++++++++-------
>   drivers/infiniband/sw/rxe/rxe_req.c  |  2 +-
>   drivers/infiniband/sw/rxe/rxe_resp.c |  2 +-
>   4 files changed, 49 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/infiniband/sw/rxe/rxe_loc.h b/drivers/infiniband/sw/rxe/rxe_loc.h
> index 0e022ae1b8a5..4da57abbbc8c 100644
> --- a/drivers/infiniband/sw/rxe/rxe_loc.h
> +++ b/drivers/infiniband/sw/rxe/rxe_loc.h
> @@ -77,7 +77,8 @@ struct rxe_mr *lookup_mr(struct rxe_pd *pd, int access, u32 key,
>   			 enum rxe_mr_lookup_type type);
>   int mr_check_range(struct rxe_mr *mr, u64 iova, size_t length);
>   int advance_dma_data(struct rxe_dma_info *dma, unsigned int length);
> -int rxe_invalidate_mr(struct rxe_qp *qp, u32 rkey);
> +int rxe_invalidate_mr_local(struct rxe_qp *qp, u32 lkey);
> +int rxe_invalidate_mr_remote(struct rxe_qp *qp, u32 rkey);
>   int rxe_reg_fast_mr(struct rxe_qp *qp, struct rxe_send_wqe *wqe);
>   int rxe_mr_set_page(struct ib_mr *ibmr, u64 addr);
>   int rxe_dereg_mr(struct ib_mr *ibmr, struct ib_udata *udata);
> diff --git a/drivers/infiniband/sw/rxe/rxe_mr.c b/drivers/infiniband/sw/rxe/rxe_mr.c
> index fc3942e04a1f..1c7179dd92eb 100644
> --- a/drivers/infiniband/sw/rxe/rxe_mr.c
> +++ b/drivers/infiniband/sw/rxe/rxe_mr.c
> @@ -576,41 +576,72 @@ struct rxe_mr *lookup_mr(struct rxe_pd *pd, int access, u32 key,
>   	return mr;
>   }
>   
> -int rxe_invalidate_mr(struct rxe_qp *qp, u32 rkey)
> +static int rxe_invalidate_mr(struct rxe_mr *mr)
> +{
> +	if (atomic_read(&mr->num_mw) > 0) {
> +		pr_warn("%s: Attempt to invalidate an MR while bound to MWs\n",
> +			__func__);
> +		return -EINVAL;
> +	}
> +
> +	if (unlikely(mr->type != IB_MR_TYPE_MEM_REG)) {
> +		pr_warn("%s: mr->type (%d) is wrong type\n", __func__, mr->type);
> +		return -EINVAL;
> +	}
> +
> +	mr->state = RXE_MR_STATE_FREE;
> +	return 0;
> +}
> +
> +int rxe_invalidate_mr_local(struct rxe_qp *qp, u32 lkey)
>   {
>   	struct rxe_dev *rxe = to_rdev(qp->ibqp.device);
>   	struct rxe_mr *mr;
>   	int ret;
>   
> -	mr = rxe_pool_get_index(&rxe->mr_pool, rkey >> 8);
> +	mr = rxe_pool_get_index(&rxe->mr_pool, lkey >> 8);
>   	if (!mr) {
> -		pr_err("%s: No MR for rkey %#x\n", __func__, rkey);
> +		pr_err("%s: No MR for lkey %#x\n", __func__, lkey);
>   		ret = -EINVAL;
>   		goto err;
>   	}
>   
> -	if (rkey != mr->rkey) {
> -		pr_err("%s: rkey (%#x) doesn't match mr->rkey (%#x)\n",
> -			__func__, rkey, mr->rkey);
> +	if (lkey != mr->lkey) {
> +		pr_err("%s: lkey (%#x) doesn't match mr->lkey (%#x)\n",
> +			__func__, lkey, mr->lkey);
>   		ret = -EINVAL;
>   		goto err_drop_ref;
>   	}
>   
> -	if (atomic_read(&mr->num_mw) > 0) {
> -		pr_warn("%s: Attempt to invalidate an MR while bound to MWs\n",
> -			__func__);
> +	ret = rxe_invalidate_mr(mr);
> +
> +err_drop_ref:
> +	rxe_put(mr);
> +err:
> +	return ret;
> +}
> +
> +int rxe_invalidate_mr_remote(struct rxe_qp *qp, u32 rkey)
> +{
> +	struct rxe_dev *rxe = to_rdev(qp->ibqp.device);
> +	struct rxe_mr *mr;
> +	int ret;
> +
> +	mr = rxe_pool_get_index(&rxe->mr_pool, rkey >> 8);
> +	if (!mr) {
> +		pr_err("%s: No MR for rkey %#x\n", __func__, rkey);
>   		ret = -EINVAL;
> -		goto err_drop_ref;
> +		goto err;
>   	}
>   
> -	if (unlikely(mr->type != IB_MR_TYPE_MEM_REG)) {
> -		pr_warn("%s: mr->type (%d) is wrong type\n", __func__, mr->type);
> +	if (rkey != mr->rkey) {
> +		pr_err("%s: rkey (%#x) doesn't match mr->rkey (%#x)\n",
> +			__func__, rkey, mr->rkey);
>   		ret = -EINVAL;
>   		goto err_drop_ref;
>   	}
>   
> -	mr->state = RXE_MR_STATE_FREE;
> -	ret = 0;
> +	ret = rxe_invalidate_mr(mr);
>   
>   err_drop_ref:
>   	rxe_put(mr);
> diff --git a/drivers/infiniband/sw/rxe/rxe_req.c b/drivers/infiniband/sw/rxe/rxe_req.c
> index 9d98237389cf..e7dd9738a255 100644
> --- a/drivers/infiniband/sw/rxe/rxe_req.c
> +++ b/drivers/infiniband/sw/rxe/rxe_req.c
> @@ -550,7 +550,7 @@ static int rxe_do_local_ops(struct rxe_qp *qp, struct rxe_send_wqe *wqe)
>   		if (rkey_is_mw(rkey))
>   			ret = rxe_invalidate_mw(qp, rkey);
>   		else
> -			ret = rxe_invalidate_mr(qp, rkey);
> +			ret = rxe_invalidate_mr_local(qp, rkey);

if this rkey would implies *lkey* or *rkey*, shall we give it a new better name ?


Thanks
Zhijian

>   
>   		if (unlikely(ret)) {
>   			wqe->status = IB_WC_LOC_QP_OP_ERR;
> diff --git a/drivers/infiniband/sw/rxe/rxe_resp.c b/drivers/infiniband/sw/rxe/rxe_resp.c
> index f4f6ee5d81fe..01411280cd73 100644
> --- a/drivers/infiniband/sw/rxe/rxe_resp.c
> +++ b/drivers/infiniband/sw/rxe/rxe_resp.c
> @@ -818,7 +818,7 @@ static int invalidate_rkey(struct rxe_qp *qp, u32 rkey)
>   	if (rkey_is_mw(rkey))
>   		return rxe_invalidate_mw(qp, rkey);
>   	else
> -		return rxe_invalidate_mr(qp, rkey);
> +		return rxe_invalidate_mr_remote(qp, rkey);
>   }
>   
>   /* Executes a new request. A retried request never reach that function (send

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] RDMA/rxe: Split rxe_invalidate_mr into local and remote versions
  2022-06-13  2:20 ` lizhijian
@ 2022-06-13 14:20   ` haris iqbal
  2022-06-24 23:27     ` Jason Gunthorpe
  0 siblings, 1 reply; 14+ messages in thread
From: haris iqbal @ 2022-06-13 14:20 UTC (permalink / raw)
  To: lizhijian
  Cc: linux-rdma, bvanassche, leon, jgg, haris.iqbal, jinpu.wang,
	aleksei.marov, rpearsonhpe

On Mon, Jun 13, 2022 at 4:20 AM lizhijian@fujitsu.com
<lizhijian@fujitsu.com> 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.

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.

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.


>
>
>
> > and for the remote one, it should happen with rkey.
> >
> > This commit splits the rxe_invalidate_mr into local and remote versions.
> > Each of them does comparison the right way as described above (with lkey
> > for local, and rkey for remote).
> >
> > Fixes: 3902b429ca14 ("RDMA/rxe: Implement invalidate MW operations")
> > Cc: rpearsonhpe@gmail.com
> > Signed-off-by: Md Haris Iqbal <haris.phnx@gmail.com>
> > ---
> >   drivers/infiniband/sw/rxe/rxe_loc.h  |  3 +-
> >   drivers/infiniband/sw/rxe/rxe_mr.c   | 59 +++++++++++++++++++++-------
> >   drivers/infiniband/sw/rxe/rxe_req.c  |  2 +-
> >   drivers/infiniband/sw/rxe/rxe_resp.c |  2 +-
> >   4 files changed, 49 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/infiniband/sw/rxe/rxe_loc.h b/drivers/infiniband/sw/rxe/rxe_loc.h
> > index 0e022ae1b8a5..4da57abbbc8c 100644
> > --- a/drivers/infiniband/sw/rxe/rxe_loc.h
> > +++ b/drivers/infiniband/sw/rxe/rxe_loc.h
> > @@ -77,7 +77,8 @@ struct rxe_mr *lookup_mr(struct rxe_pd *pd, int access, u32 key,
> >                        enum rxe_mr_lookup_type type);
> >   int mr_check_range(struct rxe_mr *mr, u64 iova, size_t length);
> >   int advance_dma_data(struct rxe_dma_info *dma, unsigned int length);
> > -int rxe_invalidate_mr(struct rxe_qp *qp, u32 rkey);
> > +int rxe_invalidate_mr_local(struct rxe_qp *qp, u32 lkey);
> > +int rxe_invalidate_mr_remote(struct rxe_qp *qp, u32 rkey);
> >   int rxe_reg_fast_mr(struct rxe_qp *qp, struct rxe_send_wqe *wqe);
> >   int rxe_mr_set_page(struct ib_mr *ibmr, u64 addr);
> >   int rxe_dereg_mr(struct ib_mr *ibmr, struct ib_udata *udata);
> > diff --git a/drivers/infiniband/sw/rxe/rxe_mr.c b/drivers/infiniband/sw/rxe/rxe_mr.c
> > index fc3942e04a1f..1c7179dd92eb 100644
> > --- a/drivers/infiniband/sw/rxe/rxe_mr.c
> > +++ b/drivers/infiniband/sw/rxe/rxe_mr.c
> > @@ -576,41 +576,72 @@ struct rxe_mr *lookup_mr(struct rxe_pd *pd, int access, u32 key,
> >       return mr;
> >   }
> >
> > -int rxe_invalidate_mr(struct rxe_qp *qp, u32 rkey)
> > +static int rxe_invalidate_mr(struct rxe_mr *mr)
> > +{
> > +     if (atomic_read(&mr->num_mw) > 0) {
> > +             pr_warn("%s: Attempt to invalidate an MR while bound to MWs\n",
> > +                     __func__);
> > +             return -EINVAL;
> > +     }
> > +
> > +     if (unlikely(mr->type != IB_MR_TYPE_MEM_REG)) {
> > +             pr_warn("%s: mr->type (%d) is wrong type\n", __func__, mr->type);
> > +             return -EINVAL;
> > +     }
> > +
> > +     mr->state = RXE_MR_STATE_FREE;
> > +     return 0;
> > +}
> > +
> > +int rxe_invalidate_mr_local(struct rxe_qp *qp, u32 lkey)
> >   {
> >       struct rxe_dev *rxe = to_rdev(qp->ibqp.device);
> >       struct rxe_mr *mr;
> >       int ret;
> >
> > -     mr = rxe_pool_get_index(&rxe->mr_pool, rkey >> 8);
> > +     mr = rxe_pool_get_index(&rxe->mr_pool, lkey >> 8);
> >       if (!mr) {
> > -             pr_err("%s: No MR for rkey %#x\n", __func__, rkey);
> > +             pr_err("%s: No MR for lkey %#x\n", __func__, lkey);
> >               ret = -EINVAL;
> >               goto err;
> >       }
> >
> > -     if (rkey != mr->rkey) {
> > -             pr_err("%s: rkey (%#x) doesn't match mr->rkey (%#x)\n",
> > -                     __func__, rkey, mr->rkey);
> > +     if (lkey != mr->lkey) {
> > +             pr_err("%s: lkey (%#x) doesn't match mr->lkey (%#x)\n",
> > +                     __func__, lkey, mr->lkey);
> >               ret = -EINVAL;
> >               goto err_drop_ref;
> >       }
> >
> > -     if (atomic_read(&mr->num_mw) > 0) {
> > -             pr_warn("%s: Attempt to invalidate an MR while bound to MWs\n",
> > -                     __func__);
> > +     ret = rxe_invalidate_mr(mr);
> > +
> > +err_drop_ref:
> > +     rxe_put(mr);
> > +err:
> > +     return ret;
> > +}
> > +
> > +int rxe_invalidate_mr_remote(struct rxe_qp *qp, u32 rkey)
> > +{
> > +     struct rxe_dev *rxe = to_rdev(qp->ibqp.device);
> > +     struct rxe_mr *mr;
> > +     int ret;
> > +
> > +     mr = rxe_pool_get_index(&rxe->mr_pool, rkey >> 8);
> > +     if (!mr) {
> > +             pr_err("%s: No MR for rkey %#x\n", __func__, rkey);
> >               ret = -EINVAL;
> > -             goto err_drop_ref;
> > +             goto err;
> >       }
> >
> > -     if (unlikely(mr->type != IB_MR_TYPE_MEM_REG)) {
> > -             pr_warn("%s: mr->type (%d) is wrong type\n", __func__, mr->type);
> > +     if (rkey != mr->rkey) {
> > +             pr_err("%s: rkey (%#x) doesn't match mr->rkey (%#x)\n",
> > +                     __func__, rkey, mr->rkey);
> >               ret = -EINVAL;
> >               goto err_drop_ref;
> >       }
> >
> > -     mr->state = RXE_MR_STATE_FREE;
> > -     ret = 0;
> > +     ret = rxe_invalidate_mr(mr);
> >
> >   err_drop_ref:
> >       rxe_put(mr);
> > diff --git a/drivers/infiniband/sw/rxe/rxe_req.c b/drivers/infiniband/sw/rxe/rxe_req.c
> > index 9d98237389cf..e7dd9738a255 100644
> > --- a/drivers/infiniband/sw/rxe/rxe_req.c
> > +++ b/drivers/infiniband/sw/rxe/rxe_req.c
> > @@ -550,7 +550,7 @@ static int rxe_do_local_ops(struct rxe_qp *qp, struct rxe_send_wqe *wqe)
> >               if (rkey_is_mw(rkey))
> >                       ret = rxe_invalidate_mw(qp, rkey);
> >               else
> > -                     ret = rxe_invalidate_mr(qp, rkey);
> > +                     ret = rxe_invalidate_mr_local(qp, rkey);
>
> if this rkey would implies *lkey* or *rkey*, shall we give it a new better name ?

True. We can change this to just "key" maybe.

Also, I do not know about mw, but can this problem occur for mw also?
Does that also need a patch?

>
>
> Thanks
> Zhijian
>
> >
> >               if (unlikely(ret)) {
> >                       wqe->status = IB_WC_LOC_QP_OP_ERR;
> > diff --git a/drivers/infiniband/sw/rxe/rxe_resp.c b/drivers/infiniband/sw/rxe/rxe_resp.c
> > index f4f6ee5d81fe..01411280cd73 100644
> > --- a/drivers/infiniband/sw/rxe/rxe_resp.c
> > +++ b/drivers/infiniband/sw/rxe/rxe_resp.c
> > @@ -818,7 +818,7 @@ static int invalidate_rkey(struct rxe_qp *qp, u32 rkey)
> >       if (rkey_is_mw(rkey))
> >               return rxe_invalidate_mw(qp, rkey);
> >       else
> > -             return rxe_invalidate_mr(qp, rkey);
> > +             return rxe_invalidate_mr_remote(qp, rkey);
> >   }
> >
> >   /* Executes a new request. A retried request never reach that function (send

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] RDMA/rxe: Split rxe_invalidate_mr into local and remote versions
  2022-06-13 14:20   ` haris iqbal
@ 2022-06-24 23:27     ` Jason Gunthorpe
  2022-06-28 16:21       ` haris iqbal
  0 siblings, 1 reply; 14+ messages in thread
From: Jason Gunthorpe @ 2022-06-24 23:27 UTC (permalink / raw)
  To: haris iqbal
  Cc: lizhijian, linux-rdma, bvanassche, leon, haris.iqbal, jinpu.wang,
	aleksei.marov, rpearsonhpe

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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] RDMA/rxe: Split rxe_invalidate_mr into local and remote versions
  2022-06-24 23:27     ` Jason Gunthorpe
@ 2022-06-28 16:21       ` haris iqbal
  2022-06-28 16:34         ` Jason Gunthorpe
  0 siblings, 1 reply; 14+ messages in thread
From: haris iqbal @ 2022-06-28 16:21 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: lizhijian, linux-rdma, bvanassche, leon, haris.iqbal, jinpu.wang,
	aleksei.marov, rpearsonhpe

On Sat, Jun 25, 2022 at 1:27 AM Jason Gunthorpe <jgg@ziepe.ca> wrote:
>
> 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.

If disjoint key space is not supported in Linux; does this mean
irrespective of whether an MR is registered (IB_WR_REG_MR) for LOCAL
or REMOTE access, both rkey and lkey should be set?

PS: This discussion started in the following thread,
https://marc.info/?l=linux-rdma&m=165390868832428&w=2

>
> 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

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] RDMA/rxe: Split rxe_invalidate_mr into local and remote versions
  2022-06-28 16:21       ` haris iqbal
@ 2022-06-28 16:34         ` Jason Gunthorpe
  2022-06-28 16:46           ` haris iqbal
  0 siblings, 1 reply; 14+ messages in thread
From: Jason Gunthorpe @ 2022-06-28 16:34 UTC (permalink / raw)
  To: haris iqbal
  Cc: lizhijian, linux-rdma, bvanassche, leon, haris.iqbal, jinpu.wang,
	aleksei.marov, rpearsonhpe

On Tue, Jun 28, 2022 at 06:21:09PM +0200, haris iqbal wrote:

> > Yes, no driver in Linux suports a disjoint key space.
> 
> If disjoint key space is not supported in Linux; does this mean
> irrespective of whether an MR is registered (IB_WR_REG_MR) for LOCAL
> or REMOTE access, both rkey and lkey should be set?

No.. It means given any key the driver can always tell if it is a rkey
or a lkey. There is never any aliasing of key values. Thus the API
often doesn't have a away to tell if the given key is an rkey or lkey.
 
> PS: This discussion started in the following thread,
> https://marc.info/?l=linux-rdma&m=165390868832428&w=2

rxe is incorrect to not accept the lkey presented on the
invalidate_rkey input. invalidate_rkey is misnamed.

Jason

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] RDMA/rxe: Split rxe_invalidate_mr into local and remote versions
  2022-06-28 16:34         ` Jason Gunthorpe
@ 2022-06-28 16:46           ` haris iqbal
  2022-06-28 16:50             ` Jason Gunthorpe
  0 siblings, 1 reply; 14+ messages in thread
From: haris iqbal @ 2022-06-28 16:46 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: lizhijian, linux-rdma, bvanassche, leon, haris.iqbal, jinpu.wang,
	aleksei.marov, rpearsonhpe

On Tue, Jun 28, 2022 at 6:34 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
>
> On Tue, Jun 28, 2022 at 06:21:09PM +0200, haris iqbal wrote:
>
> > > Yes, no driver in Linux suports a disjoint key space.
> >
> > If disjoint key space is not supported in Linux; does this mean
> > irrespective of whether an MR is registered (IB_WR_REG_MR) for LOCAL
> > or REMOTE access, both rkey and lkey should be set?
>
> No.. It means given any key the driver can always tell if it is a rkey
> or a lkey. There is never any aliasing of key values. Thus the API
> often doesn't have a away to tell if the given key is an rkey or lkey.
>
> > PS: This discussion started in the following thread,
> > https://marc.info/?l=linux-rdma&m=165390868832428&w=2
>
> rxe is incorrect to not accept the lkey presented on the
> invalidate_rkey input. invalidate_rkey is misnamed.


Understood. So a better fix for rxe (as compared to the one I sent)
would be one of the following (if I understand correctly).

1) The key sent in INV, is compared with lkey or rkey based on which
one is set (non-zero).
OR,
2) The key sent in INV, is compared with lkey if the MR has only LOCAL
access, and rkey if the MR has REMOTE access.

>
> Jason

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] RDMA/rxe: Split rxe_invalidate_mr into local and remote versions
  2022-06-28 16:46           ` haris iqbal
@ 2022-06-28 16:50             ` Jason Gunthorpe
  2022-06-28 17:05               ` haris iqbal
  0 siblings, 1 reply; 14+ messages in thread
From: Jason Gunthorpe @ 2022-06-28 16:50 UTC (permalink / raw)
  To: haris iqbal
  Cc: lizhijian, linux-rdma, bvanassche, leon, haris.iqbal, jinpu.wang,
	aleksei.marov, rpearsonhpe

On Tue, Jun 28, 2022 at 06:46:39PM +0200, haris iqbal wrote:
> On Tue, Jun 28, 2022 at 6:34 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> >
> > On Tue, Jun 28, 2022 at 06:21:09PM +0200, haris iqbal wrote:
> >
> > > > Yes, no driver in Linux suports a disjoint key space.
> > >
> > > If disjoint key space is not supported in Linux; does this mean
> > > irrespective of whether an MR is registered (IB_WR_REG_MR) for LOCAL
> > > or REMOTE access, both rkey and lkey should be set?
> >
> > No.. It means given any key the driver can always tell if it is a rkey
> > or a lkey. There is never any aliasing of key values. Thus the API
> > often doesn't have a away to tell if the given key is an rkey or lkey.
> >
> > > PS: This discussion started in the following thread,
> > > https://marc.info/?l=linux-rdma&m=165390868832428&w=2
> >
> > rxe is incorrect to not accept the lkey presented on the
> > invalidate_rkey input. invalidate_rkey is misnamed.
> 
> 
> Understood. So a better fix for rxe (as compared to the one I sent)
> would be one of the following (if I understand correctly).
> 
> 1) The key sent in INV, is compared with lkey or rkey based on which
> one is set (non-zero).

This one seems to match the spec

However, it requires that keys don't alias, I don't know if rxe has
done this.

> OR,
> 2) The key sent in INV, is compared with lkey if the MR has only LOCAL
> access, and rkey if the MR has REMOTE access.

That might make more sense if rxe has aliasing keys and you need to be
specific about r/l

Jason

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] RDMA/rxe: Split rxe_invalidate_mr into local and remote versions
  2022-06-28 16:50             ` Jason Gunthorpe
@ 2022-06-28 17:05               ` haris iqbal
  2022-06-28 20:04                 ` Bob Pearson
  0 siblings, 1 reply; 14+ messages in thread
From: haris iqbal @ 2022-06-28 17:05 UTC (permalink / raw)
  To: Jason Gunthorpe
  Cc: lizhijian, linux-rdma, bvanassche, leon, haris.iqbal, jinpu.wang,
	aleksei.marov, rpearsonhpe

On Tue, Jun 28, 2022 at 6:50 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
>
> On Tue, Jun 28, 2022 at 06:46:39PM +0200, haris iqbal wrote:
> > On Tue, Jun 28, 2022 at 6:34 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> > >
> > > On Tue, Jun 28, 2022 at 06:21:09PM +0200, haris iqbal wrote:
> > >
> > > > > Yes, no driver in Linux suports a disjoint key space.
> > > >
> > > > If disjoint key space is not supported in Linux; does this mean
> > > > irrespective of whether an MR is registered (IB_WR_REG_MR) for LOCAL
> > > > or REMOTE access, both rkey and lkey should be set?
> > >
> > > No.. It means given any key the driver can always tell if it is a rkey
> > > or a lkey. There is never any aliasing of key values. Thus the API
> > > often doesn't have a away to tell if the given key is an rkey or lkey.
> > >
> > > > PS: This discussion started in the following thread,
> > > > https://marc.info/?l=linux-rdma&m=165390868832428&w=2
> > >
> > > rxe is incorrect to not accept the lkey presented on the
> > > invalidate_rkey input. invalidate_rkey is misnamed.
> >
> >
> > Understood. So a better fix for rxe (as compared to the one I sent)
> > would be one of the following (if I understand correctly).
> >
> > 1) The key sent in INV, is compared with lkey or rkey based on which
> > one is set (non-zero).
>
> This one seems to match the spec
>
> However, it requires that keys don't alias, I don't know if rxe has
> done this.

Rxe seems to be NOT aliasing for fast reg. Unsure about other cases.

Maybe Bob or Zhu can shed some light?

>
> > OR,
> > 2) The key sent in INV, is compared with lkey if the MR has only LOCAL
> > access, and rkey if the MR has REMOTE access.
>
> That might make more sense if rxe has aliasing keys and you need to be
> specific about r/l
>
> Jason

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] RDMA/rxe: Split rxe_invalidate_mr into local and remote versions
  2022-06-28 17:05               ` haris iqbal
@ 2022-06-28 20:04                 ` Bob Pearson
  2022-06-29 12:56                   ` haris iqbal
  0 siblings, 1 reply; 14+ messages in thread
From: Bob Pearson @ 2022-06-28 20:04 UTC (permalink / raw)
  To: haris iqbal, Jason Gunthorpe
  Cc: lizhijian, linux-rdma, bvanassche, leon, haris.iqbal, jinpu.wang,
	aleksei.marov

On 6/28/22 12:05, haris iqbal wrote:
> On Tue, Jun 28, 2022 at 6:50 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
>>
>> On Tue, Jun 28, 2022 at 06:46:39PM +0200, haris iqbal wrote:
>>> On Tue, Jun 28, 2022 at 6:34 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
>>>>
>>>> On Tue, Jun 28, 2022 at 06:21:09PM +0200, haris iqbal wrote:
>>>>
>>>>>> Yes, no driver in Linux suports a disjoint key space.
>>>>>
>>>>> If disjoint key space is not supported in Linux; does this mean
>>>>> irrespective of whether an MR is registered (IB_WR_REG_MR) for LOCAL
>>>>> or REMOTE access, both rkey and lkey should be set?
>>>>
>>>> No.. It means given any key the driver can always tell if it is a rkey
>>>> or a lkey. There is never any aliasing of key values. Thus the API
>>>> often doesn't have a away to tell if the given key is an rkey or lkey.
>>>>
>>>>> PS: This discussion started in the following thread,
>>>>> https://marc.info/?l=linux-rdma&m=165390868832428&w=2
>>>>
>>>> rxe is incorrect to not accept the lkey presented on the
>>>> invalidate_rkey input. invalidate_rkey is misnamed.
>>>
>>>
>>> Understood. So a better fix for rxe (as compared to the one I sent)
>>> would be one of the following (if I understand correctly).
>>>
>>> 1) The key sent in INV, is compared with lkey or rkey based on which
>>> one is set (non-zero).
>>
>> This one seems to match the spec
>>
>> However, it requires that keys don't alias, I don't know if rxe has
>> done this.
> 
> Rxe seems to be NOT aliasing for fast reg. Unsure about other cases.
> 
> Maybe Bob or Zhu can shed some light?
> 
>>
>>> OR,
>>> 2) The key sent in INV, is compared with lkey if the MR has only LOCAL
>>> access, and rkey if the MR has REMOTE access.
>>
>> That might make more sense if rxe has aliasing keys and you need to be
>> specific about r/l
>>
>> Jason

rxe always has lkey=rkey if rkey is asked for else rkey=0 and lkey is always set.

Bob

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] RDMA/rxe: Split rxe_invalidate_mr into local and remote versions
  2022-06-28 20:04                 ` Bob Pearson
@ 2022-06-29 12:56                   ` haris iqbal
  2022-06-29 15:04                     ` Pearson, Robert B
  0 siblings, 1 reply; 14+ messages in thread
From: haris iqbal @ 2022-06-29 12:56 UTC (permalink / raw)
  To: Bob Pearson
  Cc: Jason Gunthorpe, lizhijian, linux-rdma, bvanassche, leon,
	haris.iqbal, jinpu.wang, aleksei.marov

On Tue, Jun 28, 2022 at 10:04 PM Bob Pearson <rpearsonhpe@gmail.com> wrote:
>
> On 6/28/22 12:05, haris iqbal wrote:
> > On Tue, Jun 28, 2022 at 6:50 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> >>
> >> On Tue, Jun 28, 2022 at 06:46:39PM +0200, haris iqbal wrote:
> >>> On Tue, Jun 28, 2022 at 6:34 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> >>>>
> >>>> On Tue, Jun 28, 2022 at 06:21:09PM +0200, haris iqbal wrote:
> >>>>
> >>>>>> Yes, no driver in Linux suports a disjoint key space.
> >>>>>
> >>>>> If disjoint key space is not supported in Linux; does this mean
> >>>>> irrespective of whether an MR is registered (IB_WR_REG_MR) for LOCAL
> >>>>> or REMOTE access, both rkey and lkey should be set?
> >>>>
> >>>> No.. It means given any key the driver can always tell if it is a rkey
> >>>> or a lkey. There is never any aliasing of key values. Thus the API
> >>>> often doesn't have a away to tell if the given key is an rkey or lkey.
> >>>>
> >>>>> PS: This discussion started in the following thread,
> >>>>> https://marc.info/?l=linux-rdma&m=165390868832428&w=2
> >>>>
> >>>> rxe is incorrect to not accept the lkey presented on the
> >>>> invalidate_rkey input. invalidate_rkey is misnamed.
> >>>
> >>>
> >>> Understood. So a better fix for rxe (as compared to the one I sent)
> >>> would be one of the following (if I understand correctly).
> >>>
> >>> 1) The key sent in INV, is compared with lkey or rkey based on which
> >>> one is set (non-zero).
> >>
> >> This one seems to match the spec
> >>
> >> However, it requires that keys don't alias, I don't know if rxe has
> >> done this.
> >
> > Rxe seems to be NOT aliasing for fast reg. Unsure about other cases.
> >
> > Maybe Bob or Zhu can shed some light?
> >
> >>
> >>> OR,
> >>> 2) The key sent in INV, is compared with lkey if the MR has only LOCAL
> >>> access, and rkey if the MR has REMOTE access.
> >>
> >> That might make more sense if rxe has aliasing keys and you need to be
> >> specific about r/l
> >>
> >> Jason
>
> rxe always has lkey=rkey if rkey is asked for else rkey=0 and lkey is always set.

When you say "rkey is asked for", you mean the access permissions
(LOCAL/REMOTE) asked for that MR right?

If so, then for RXE to decide which key to compare with while
invalidating, it's better to decide based on the access of the MR
(basically fix number 2 from my older email).

>
> Bob

^ permalink raw reply	[flat|nested] 14+ messages in thread

* RE: [PATCH] RDMA/rxe: Split rxe_invalidate_mr into local and remote versions
  2022-06-29 12:56                   ` haris iqbal
@ 2022-06-29 15:04                     ` Pearson, Robert B
  2022-06-29 15:30                       ` haris iqbal
  0 siblings, 1 reply; 14+ messages in thread
From: Pearson, Robert B @ 2022-06-29 15:04 UTC (permalink / raw)
  To: haris iqbal, Bob Pearson
  Cc: Jason Gunthorpe, lizhijian, linux-rdma, bvanassche, leon,
	haris.iqbal, jinpu.wang, aleksei.marov



-----Original Message-----
From: haris iqbal <haris.phnx@gmail.com> 
Sent: Wednesday, June 29, 2022 7:57 AM
To: Bob Pearson <rpearsonhpe@gmail.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>; lizhijian@fujitsu.com; linux-rdma@vger.kernel.org; bvanassche@acm.org; leon@kernel.org; haris.iqbal@ionos.com; jinpu.wang@ionos.com; aleksei.marov@ionos.com
Subject: Re: [PATCH] RDMA/rxe: Split rxe_invalidate_mr into local and remote versions

On Tue, Jun 28, 2022 at 10:04 PM Bob Pearson <rpearsonhpe@gmail.com> wrote:
>
> On 6/28/22 12:05, haris iqbal wrote:
> > On Tue, Jun 28, 2022 at 6:50 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> >>
> >> On Tue, Jun 28, 2022 at 06:46:39PM +0200, haris iqbal wrote:
> >>> On Tue, Jun 28, 2022 at 6:34 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> >>>>
> >>>> On Tue, Jun 28, 2022 at 06:21:09PM +0200, haris iqbal wrote:
> >>>>
> >>>>>> Yes, no driver in Linux suports a disjoint key space.
> >>>>>
> >>>>> If disjoint key space is not supported in Linux; does this mean 
> >>>>> irrespective of whether an MR is registered (IB_WR_REG_MR) for 
> >>>>> LOCAL or REMOTE access, both rkey and lkey should be set?
> >>>>
> >>>> No.. It means given any key the driver can always tell if it is a 
> >>>> rkey or a lkey. There is never any aliasing of key values. Thus 
> >>>> the API often doesn't have a away to tell if the given key is an rkey or lkey.
> >>>>
> >>>>> PS: This discussion started in the following thread,
> >>>>> https://marc.info/?l=linux-rdma&m=165390868832428&w=2
> >>>>
> >>>> rxe is incorrect to not accept the lkey presented on the 
> >>>> invalidate_rkey input. invalidate_rkey is misnamed.
> >>>
> >>>
> >>> Understood. So a better fix for rxe (as compared to the one I 
> >>> sent) would be one of the following (if I understand correctly).
> >>>
> >>> 1) The key sent in INV, is compared with lkey or rkey based on 
> >>> which one is set (non-zero).
> >>
> >> This one seems to match the spec
> >>
> >> However, it requires that keys don't alias, I don't know if rxe has 
> >> done this.
> >
> > Rxe seems to be NOT aliasing for fast reg. Unsure about other cases.
> >
> > Maybe Bob or Zhu can shed some light?
> >
> >>
> >>> OR,
> >>> 2) The key sent in INV, is compared with lkey if the MR has only 
> >>> LOCAL access, and rkey if the MR has REMOTE access.
> >>
> >> That might make more sense if rxe has aliasing keys and you need to 
> >> be specific about r/l
> >>
> >> Jason
>
> rxe always has lkey=rkey if rkey is asked for else rkey=0 and lkey is always set.

When you say "rkey is asked for", you mean the access permissions
(LOCAL/REMOTE) asked for that MR right?

Correct.

If so, then for RXE to decide which key to compare with while invalidating, it's better to decide based on the access of the MR (basically fix number 2 from my older email).

>
> Bob

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [PATCH] RDMA/rxe: Split rxe_invalidate_mr into local and remote versions
  2022-06-29 15:04                     ` Pearson, Robert B
@ 2022-06-29 15:30                       ` haris iqbal
  0 siblings, 0 replies; 14+ messages in thread
From: haris iqbal @ 2022-06-29 15:30 UTC (permalink / raw)
  To: Pearson, Robert B
  Cc: Bob Pearson, Jason Gunthorpe, lizhijian, linux-rdma, bvanassche,
	leon, haris.iqbal, jinpu.wang, aleksei.marov

On Wed, Jun 29, 2022 at 5:04 PM Pearson, Robert B
<robert.pearson2@hpe.com> wrote:
>
>
>
> -----Original Message-----
> From: haris iqbal <haris.phnx@gmail.com>
> Sent: Wednesday, June 29, 2022 7:57 AM
> To: Bob Pearson <rpearsonhpe@gmail.com>
> Cc: Jason Gunthorpe <jgg@ziepe.ca>; lizhijian@fujitsu.com; linux-rdma@vger.kernel.org; bvanassche@acm.org; leon@kernel.org; haris.iqbal@ionos.com; jinpu.wang@ionos.com; aleksei.marov@ionos.com
> Subject: Re: [PATCH] RDMA/rxe: Split rxe_invalidate_mr into local and remote versions
>
> On Tue, Jun 28, 2022 at 10:04 PM Bob Pearson <rpearsonhpe@gmail.com> wrote:
> >
> > On 6/28/22 12:05, haris iqbal wrote:
> > > On Tue, Jun 28, 2022 at 6:50 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> > >>
> > >> On Tue, Jun 28, 2022 at 06:46:39PM +0200, haris iqbal wrote:
> > >>> On Tue, Jun 28, 2022 at 6:34 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> > >>>>
> > >>>> On Tue, Jun 28, 2022 at 06:21:09PM +0200, haris iqbal wrote:
> > >>>>
> > >>>>>> Yes, no driver in Linux suports a disjoint key space.
> > >>>>>
> > >>>>> If disjoint key space is not supported in Linux; does this mean
> > >>>>> irrespective of whether an MR is registered (IB_WR_REG_MR) for
> > >>>>> LOCAL or REMOTE access, both rkey and lkey should be set?
> > >>>>
> > >>>> No.. It means given any key the driver can always tell if it is a
> > >>>> rkey or a lkey. There is never any aliasing of key values. Thus
> > >>>> the API often doesn't have a away to tell if the given key is an rkey or lkey.
> > >>>>
> > >>>>> PS: This discussion started in the following thread,
> > >>>>> https://marc.info/?l=linux-rdma&m=165390868832428&w=2
> > >>>>
> > >>>> rxe is incorrect to not accept the lkey presented on the
> > >>>> invalidate_rkey input. invalidate_rkey is misnamed.
> > >>>
> > >>>
> > >>> Understood. So a better fix for rxe (as compared to the one I
> > >>> sent) would be one of the following (if I understand correctly).
> > >>>
> > >>> 1) The key sent in INV, is compared with lkey or rkey based on
> > >>> which one is set (non-zero).
> > >>
> > >> This one seems to match the spec
> > >>
> > >> However, it requires that keys don't alias, I don't know if rxe has
> > >> done this.
> > >
> > > Rxe seems to be NOT aliasing for fast reg. Unsure about other cases.
> > >
> > > Maybe Bob or Zhu can shed some light?
> > >
> > >>
> > >>> OR,
> > >>> 2) The key sent in INV, is compared with lkey if the MR has only
> > >>> LOCAL access, and rkey if the MR has REMOTE access.
> > >>
> > >> That might make more sense if rxe has aliasing keys and you need to
> > >> be specific about r/l
> > >>
> > >> Jason
> >
> > rxe always has lkey=rkey if rkey is asked for else rkey=0 and lkey is always set.
>
> When you say "rkey is asked for", you mean the access permissions
> (LOCAL/REMOTE) asked for that MR right?
>
> Correct.

Thanks. I will send a patch with the discussed changes for invalidate.

>
> If so, then for RXE to decide which key to compare with while invalidating, it's better to decide based on the access of the MR (basically fix number 2 from my older email).
>
> >
> > Bob

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2022-06-29 15:31 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).