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;
From:   "Alim Akhtar" <alim.akhtar@samsung.com>
To:     "'Avri Altman'" <Avri.Altman@wdc.com>, <huobean@gmail.com>,
        <asutoshd@codeaurora.org>, <jejb@linux.ibm.com>,
        <martin.petersen@oracle.com>, <stanley.chu@mediatek.com>,
        <beanhuo@micron.com>, <bvanassche@acm.org>,
        <tomas.winkler@intel.com>, <cang@codeaurora.org>,
        <rdunlap@infradead.org>, <seunguk.shin@samsung.com>
Cc:     <linux-scsi@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <hch@infradead.org>
In-Reply-To: <BYAPR04MB462904DA704A8FD42436BA9FFCA20@BYAPR04MB4629.namprd04.prod.outlook.com>
Subject: RE: [RESENT PATCH RFC v3 5/5] scsi: ufs: UFS Host Performance
 Booster(HPB) driver
Date:   Fri, 8 May 2020 19:56:16 +0530
Message-ID: <000401d62544$ab93ead0$02bbc070$@samsung.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQJO+B8HmB53n8gOhlSxo4VvqTv/wAGtj2ZpAcmq4aIBR3FF8aeGntbw
Content-Language: en-in
Content-Type: text/plain; charset="utf-8"
CMS-TYPE: 105P
References: <20200504142032.16619-1-beanhuo@micron.com>
        <20200504142032.16619-6-beanhuo@micron.com>
        <CGME20200508113840epcas5p1cee545219dd59b64eeea287f17d34cde@epcas5p1.samsung.com>
        <BYAPR04MB462904DA704A8FD42436BA9FFCA20@BYAPR04MB4629.namprd04.prod.outlook.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

+ seunguk.shin (who is one of the original author of the HPB, in case he ha=
s some more improvement inputs)

Hi Bean,
I second Avri input on splitting this patch series into logical smaller pat=
ches, that will helps reviewers.
Also if you can add support to build HPB as kernel module that will be usef=
ul.=20
I am looking into the HPB 1.0 spec, will review your patches soon.

Regards,
Alim

> -----Original Message-----
> From: Avri Altman <Avri.Altman=40wdc.com>
> Sent: 08 May 2020 17:09
> To: huobean=40gmail.com; alim.akhtar=40samsung.com;
> asutoshd=40codeaurora.org; jejb=40linux.ibm.com; martin.petersen=40oracle=
.com;
> stanley.chu=40mediatek.com; beanhuo=40micron.com; bvanassche=40acm.org;
> tomas.winkler=40intel.com; cang=40codeaurora.org; rdunlap=40infradead.org
> Cc: linux-scsi=40vger.kernel.org; linux-kernel=40vger.kernel.org;
> hch=40infradead.org
> Subject: RE: =5BRESENT PATCH RFC v3 5/5=5D scsi: ufs: UFS Host Performanc=
e
> Booster(HPB) driver
>=20
> Hi Bean,
> This patch is =7E3,000 lines long.
> Is it possible to divide it into a series of a smaller, more reviewable p=
atches?
> E.g. it can be something like:
> 1) Init part I - Read HPB config
> 2) Init part II - prepare for L2P cache management (introduce here all th=
e new
> data structures, memory allocation, etc.)
> 3) L2P cache management - activation / inactivation / eviction handlers
> 4) Add response API
> 5) Add prep_fn handler - the flows that contruct HPB-READ command.
> Or any other division that makes sense to you.
>=20
> Also, Is there a way to avoid all those =23ifdefs everywhere?
>=20
> Thanks,
> Avri
>=20
>=20
> >
> > From: Bean Huo <beanhuo=40micron.com>
> >
> > This patch is to add support for the UFS Host Performance Booster (HPB
> > v1.0), which is used to improve UFS read performance, especially for
> > the random read.
> >
> > NAND flash-based storage devices, including UFS, have mechanisms to
> > translate logical addresses of requests to the corresponding physical
> > addresses of the flash storage. Traditionally this L2P mapping data is
> > loaded to the internal SRAM in the storage controller. When the
> > capacity of storage is larger, a larger size of SRAM for the L2P map
> > data is required. Since increased SRAM size affects the manufacturing
> > cost significantly, it is not cost-effective to allocate all the
> > amount of SRAM needed to keep all the Logical-address to
> > Physical-address (L2P) map data. Therefore, L2P map data, which is
> > required to identify the physical address for the requested IOs, can
> > only be partially stored in SRAM from NAND flash. Due to this partial
> > loading, accessing the flash address area where the L2P information
> > for that address is not loaded in the SRAM can result in serious perfor=
mance
> degradation.
> >
> > The HPB is a software solution for the above problem, which uses the
> > host=E2=80=99s=20system=20memory=20as=20a=20cache=20for=20the=20FTL=20L=
2P=20mapping=20table.=20It=20does=0D=0A>=20>=20not=20need=20additional=20ha=
rdware=20support=20from=20the=20host=20side.=20By=20using=20HPB,=0D=0A>=20>=
=20the=20L2P=20mapping=20table=20can=20be=20read=20from=20host=20memory=20a=
nd=20stored=20in=0D=0A>=20>=20host-side=20memory.=20while=20reading=20the=
=20operation,=20the=20corresponding=20L2P=0D=0A>=20>=20information=20will=
=20be=20sent=20to=20the=20UFS=20device=20along=20with=20the=20reading=0D=0A=
>=20>=20request.=20Since=20the=20L2P=20entry=20is=20provided=20in=20the=20r=
ead=20request,=20UFS=0D=0A>=20>=20device=20does=20not=20have=20to=20load=20=
L2P=20entry=20from=20flash=20memory.=0D=0A>=20>=20This=20will=20significant=
ly=20improve=20random=20read=20performance.=0D=0A>=20>=0D=0A>=20>=20Signed-=
off-by:=20Bean=20Huo=20<beanhuo=40micron.com>=0D=0A>=20>=20---=0D=0A>=20>=
=20=20drivers/scsi/ufs/Kconfig=20=20=7C=20=20=2062=20+=0D=0A>=20>=20=20driv=
ers/scsi/ufs/Makefile=20=7C=20=20=20=201=20+=0D=0A>=20>=20=20drivers/scsi/u=
fs/ufshcd.c=20=7C=20=20234=20+++-=0D=0A>=20>=20=20drivers/scsi/ufs/ufshcd.h=
=20=7C=20=20=2023=20+=0D=0A>=20>=20=20drivers/scsi/ufs/ufshpb.c=20=7C=20276=
7=0D=0A>=20>=20+++++++++++++++++++++++++++++++++++++=0D=0A>=20>=20=20driver=
s/scsi/ufs/ufshpb.h=20=7C=20=20423=20++++++=0D=0A>=20>=20=206=20files=20cha=
nged,=203504=20insertions(+),=206=20deletions(-)=20=20create=20mode=0D=0A>=
=20>=20100644=20drivers/scsi/ufs/ufshpb.c=20=20create=20mode=20100644=0D=0A=
>=20>=20drivers/scsi/ufs/ufshpb.h=0D=0A>=20>=0D=0A=0D=0A