Re: [PATCH WIP 38/43] iser-target: Port to new memory registration API

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

 



On 7/22/2015 8:04 PM, Christoph Hellwig wrote:
@@ -2585,11 +2517,9 @@ isert_fast_reg_mr(struct isert_conn *isert_conn,
  	struct isert_device *device = isert_conn->device;
  	struct ib_device *ib_dev = device->ib_device;
  	struct ib_mr *mr;
  	struct ib_send_wr fr_wr, inv_wr;
  	struct ib_send_wr *bad_wr, *wr = NULL;
+	int ret;

  	if (mem->dma_nents == 1) {
  		sge->lkey = device->mr->lkey;
@@ -2600,40 +2530,32 @@ isert_fast_reg_mr(struct isert_conn *isert_conn,
  		return 0;
  	}

+	if (ind == ISERT_DATA_KEY_VALID)
  		/* Registering data buffer */
  		mr = fr_desc->data_mr;
+	else
  		/* Registering protection buffer */
  		mr = fr_desc->pi_ctx->prot_mr;

  	if (!(fr_desc->ind & ind)) {
  		isert_inv_rkey(&inv_wr, mr);
  		wr = &inv_wr;
  	}

+	ret = ib_map_mr_sg(mr, mem->sg, mem->nents, IB_ACCESS_LOCAL_WRITE);
+	if (ret) {
+		isert_err("failed to map sg %p with %d entries\n",
+			 mem->sg, mem->dma_nents);
+		return ret;
+	}
+
+	isert_dbg("Use fr_desc %p sg_nents %d offset %u\n",
+		  fr_desc, mem->nents, mem->offset);
+
  	/* Prepare FASTREG WR */
  	memset(&fr_wr, 0, sizeof(fr_wr));
+	ib_set_fastreg_wr(mr, mr->lkey, ISER_FASTREG_LI_WRID,
+			  false, &fr_wr);

Shouldn't ib_set_fastreg_wr take care of this memset?  Also it seems
instead of the singalled flag to it we might just set that or
other flags later if we really want to.

The reason I didn't put it in was that ib_send_wr is not a small struct
(92 bytes IIRC). So I'm a bit reluctant to add an unconditional memset.
Maybe it's better that the callers can carefully set it to save some
cycles?


  struct pi_context {
  	struct ib_mr		       *prot_mr;
-	struct ib_fast_reg_page_list   *prot_frpl;
  	struct ib_mr		       *sig_mr;
  };

  struct fast_reg_descriptor {
  	struct list_head		list;
  	struct ib_mr		       *data_mr;
-	struct ib_fast_reg_page_list   *data_frpl;
  	u8				ind;
  	struct pi_context	       *pi_ctx;

As a follow on it might be worth to just kill off the separate
pi_context structure here.

Yea we can do that..
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[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