lkml.org 
[lkml]   [2020]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC PATCH v2 4/5] scsi: ufs: L2P map management for HPB read
    From
    Date
    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



    \
     
     \ /
      Last update: 2020-06-15 15:36    [W:4.672 / U:0.668 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site