Hi Daejun
On Mon, 2020-06-15 at 18:30 +0900, Daejun Park wrote:
> +static int ufshpb_execute_map_req(struct ufshpb_lu *hpb,
> + struct ufshpb_req *map_req)
> +{
> + struct request_queue *q;
> + struct request *req;
> + struct scsi_request *rq;
> + int ret = 0;
> +
> + q = hpb->sdev_ufs_lu->request_queue;
> + ret = ufshpb_map_req_add_bio_page(hpb, q, map_req->bio,
> + map_req->mctx);
> + if (ret) {
> + dev_notice(&hpb->hpb_lu_dev,
> + "map_req_add_bio_page fail %d - %d\n",
> + map_req->rgn_idx, map_req->srgn_idx);
> + return ret;
> + }
> +
> + req = map_req->req;
> +
> + blk_rq_append_bio(req, &map_req->bio);
> +
> + req->timeout = 0;
> + req->end_io_data = (void *)map_req;
> +
> + rq = scsi_req(req);
> + ufshpb_set_read_buf_cmd(rq->cmd, map_req->rgn_idx,
> + map_req->srgn_idx, hpb-
> >srgn_mem_size);
> + rq->cmd_len = HPB_READ_BUFFER_CMD_LENGTH;
> +
> + blk_execute_rq_nowait(q, NULL, req, 1,
> ufshpb_map_req_compl_fn);
HPB map_req is now being en-queued in sdev->request_queue.
This is ok for the HPB v1.0. Have you ever been thinking about
changing this way to directly issue HPB requests to UFS?
Actually, there are two reasons for this way:
1. Latency of loading mapping entries is lower comparing to your curret
approach.
2. Also, it is preparing for the HPB v2.0. After all HPB 1.0 only
supports 4KB read, this is useless, I am looking for the HPB v2.0.
Thanks,
Bean
