Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <078bb71ddc9cda4454d213333afa4b6a905b8b09.camel@gmail.com>
Subject: Re: [RFC PATCH v2 4/5] scsi: ufs: L2P map management for HPB read
From:   Bean Huo <huobean@gmail.com>
To:     daejun7.park@samsung.com, ALIM AKHTAR <alim.akhtar@samsung.com>,
        "avri.altman@wdc.com" <avri.altman@wdc.com>,
        "jejb@linux.ibm.com" <jejb@linux.ibm.com>,
        "martin.petersen@oracle.com" <martin.petersen@oracle.com>,
        "asutoshd@codeaurora.org" <asutoshd@codeaurora.org>,
        "beanhuo@micron.com" <beanhuo@micron.com>,
        "stanley.chu@mediatek.com" <stanley.chu@mediatek.com>,
        "cang@codeaurora.org" <cang@codeaurora.org>,
        "bvanassche@acm.org" <bvanassche@acm.org>,
        "tomas.winkler@intel.com" <tomas.winkler@intel.com>
Cc:     "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Sang-yoon Oh <sangyoon.oh@samsung.com>,
        Sung-Jun Park <sungjun07.park@samsung.com>,
        yongmyung lee <ymhungry.lee@samsung.com>,
        Jinyoung CHOI <j-young.choi@samsung.com>,
        Adel Choi <adel.choi@samsung.com>,
        BoRam Shin <boram.shin@samsung.com>
Date:   Mon, 15 Jun 2020 15:35:47 +0200
In-Reply-To: <231786897.01592214002170.JavaMail.epsvc@epcpadp1>
References: <231786897.01592213402355.JavaMail.epsvc@epcpadp1>
         <231786897.01592212081335.JavaMail.epsvc@epcpadp2>
         <336371513.41592205783606.JavaMail.epsvc@epcpadp2>
         <231786897.01592205482200.JavaMail.epsvc@epcpadp2>
         <CGME20200615062708epcms2p19a7fbc051bcd5e843c29dcd58fff4210@epcms2p7>
         <231786897.01592214002170.JavaMail.epsvc@epcpadp1>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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