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;
Mime-Version: 1.0
Subject: RE: RE: [PATCH v22 4/4] scsi: ufs: Add HPB 2.0 support
Reply-To: daejun7.park@samsung.com
Sender: Daejun Park <daejun7.park@samsung.com>
From:   Daejun Park <daejun7.park@samsung.com>
To:     Avri Altman <Avri.Altman@wdc.com>,
        Daejun Park <daejun7.park@samsung.com>,
        Greg KH <gregkh@linuxfoundation.org>,
        "jejb@linux.ibm.com" <jejb@linux.ibm.com>,
        "martin.petersen@oracle.com" <martin.petersen@oracle.com>,
        "asutoshd@codeaurora.org" <asutoshd@codeaurora.org>,
        "stanley.chu@mediatek.com" <stanley.chu@mediatek.com>,
        "cang@codeaurora.org" <cang@codeaurora.org>,
        "bvanassche@acm.org" <bvanassche@acm.org>,
        "huobean@gmail.com" <huobean@gmail.com>,
        ALIM AKHTAR <alim.akhtar@samsung.com>,
        Javier Gonzalez <javier.gonz@samsung.com>
CC:     "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        JinHwan Park <jh.i.park@samsung.com>,
        SEUNGUK SHIN <seunguk.shin@samsung.com>,
        Sung-Jun Park <sungjun07.park@samsung.com>,
        yongmyung lee <ymhungry.lee@samsung.com>,
        Jinyoung CHOI <j-young.choi@samsung.com>,
        BoRam Shin <boram.shin@samsung.com>
In-Reply-To: <DM6PR04MB6575DA862FD50130DAF1E573FC809@DM6PR04MB6575.namprd04.prod.outlook.com>
Message-ID: <20210223235458epcms2p666e7cca021e09c715ca3b11ada39ebeb@epcms2p6>
Date:   Wed, 24 Feb 2021 08:54:58 +0900
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
CMS-TYPE: 102P
DLP-Filter: Pass
References: <DM6PR04MB6575DA862FD50130DAF1E573FC809@DM6PR04MB6575.namprd04.prod.outlook.com>
        <20210222092957epcms2p728b0c563f3cfbecbf8692d7e86f9afed@epcms2p7>
        <20210222092907epcms2p307f3c4116349ebde6eed05c767287449@epcms2p3>
        <20210222093150epcms2p155352e2255e6bfd8f8d71c737ed05e76@epcms2p1>
        <CGME20210222092907epcms2p307f3c4116349ebde6eed05c767287449@epcms2p6>
Precedence: bulk

> > @@ -2656,7 +2656,12 @@ static int ufshcd_queuecommand(struct Scsi_Host
> > *host, struct scsi_cmnd *cmd)
> > 
> >         lrbp->req_abort_skip = false;
> > 
> > -       ufshpb_prep(hba, lrbp);
> > +       err = ufshpb_prep(hba, lrbp);
> > +       if (err == -EAGAIN) {
> > +               lrbp->cmd = NULL;
> > +               ufshcd_release(hba);
> > +               goto out;
> > +       }
> Did I miss-read it, or are you bailing out of wb failed e.g. because no tag is available?
> Why not continue with read10?

We try to sending HPB read several times within the requeue_timeout_ms.
Because it strategy has more benefit for overall performance in this
situation that many requests are queueing.

>  
>  
> > +       if (blk_insert_cloned_request(q, req) != BLK_STS_OK)
> > +               return -EAGAIN;
> Why did you choose to use blk_insert_cloned_request and not e.g. the more common blk_execute_rq_nowait?

It is the process that sending one more command (write buffer) prior to
HPB read command. This API makes write buffer to issue directly. Other APIs,
for example blk_execute_rq_nowait, it can make queueing the command in the
scheduler, so the order of commands can be inversed.
Here is comment of the API.
// blk_insert_cloned_request - Helper for stacking drivers to submit a request

> > +       hpb->stats.pre_req_cnt++;
> > +
> > +       return 0;
> > +}
>  
> > -       ufshpb_set_hpb_read_to_upiu(hpb, lrbp, lpn, ppn, transfer_len);
> > +       if (ufshpb_is_required_wb(hpb, transfer_len)) {
> > +               err = ufshpb_issue_pre_req(hpb, cmd, &read_id);
> > +               if (err) {
> > +                       unsigned long timeout;
> > +
> > +                       timeout = cmd->jiffies_at_alloc + msecs_to_jiffies(
> > +                                 hpb->params.requeue_timeout_ms);
> > +                       if (time_before(jiffies, timeout))
> > +                               return -EAGAIN;
> Why requeue_timeout_ms needs to be a configurable parameter?
> Why rq->timeout is not enough?

We are using this value for re-trying threshold of HPB read.

Thanks,
Daejun

> Thanks,
> Avri
>  
>  
>  
>  
>