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: 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: <DM6PR04MB65754EE70E1E61C46309AF9DFC9F9@DM6PR04MB6575.namprd04.prod.outlook.com>
Message-ID: <20210225024246epcms2p76340994168c3985fcb55106ba54463ef@epcms2p7>
Date:   Thu, 25 Feb 2021 11:42:46 +0900
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
CMS-TYPE: 102P
DLP-Filter: Pass
References: <DM6PR04MB65754EE70E1E61C46309AF9DFC9F9@DM6PR04MB6575.namprd04.prod.outlook.com>
        <DM6PR04MB6575DA862FD50130DAF1E573FC809@DM6PR04MB6575.namprd04.prod.outlook.com>
        <20210222092957epcms2p728b0c563f3cfbecbf8692d7e86f9afed@epcms2p7>
        <20210222092907epcms2p307f3c4116349ebde6eed05c767287449@epcms2p3>
        <20210222093150epcms2p155352e2255e6bfd8f8d71c737ed05e76@epcms2p1>
        <20210223235458epcms2p666e7cca021e09c715ca3b11ada39ebeb@epcms2p6>
        <DM6PR04MB657573102C577230A3079DBBFC9F9@DM6PR04MB6575.namprd04.prod.outlook.com>
        <CGME20210222092907epcms2p307f3c4116349ebde6eed05c767287449@epcms2p7>
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.
> > This extra logic, IMO, should be optional.  Default none.
> > And yes, in this case requeue_timeout should be a parameter for each OEM to
> > scale.
> And either way, hpb internal flows should not cause dumping the command.
> Worse case - continue as READ10

However, this can improve the overall performance and should be used
carefully. The problem can be solved by setting the default timeout
ms to 0. And OEM can change it.

Thanks,
Daejun