>
> On 2020-04-26 23:13, Avri Altman wrote:
> >> On 2020-04-25 01:59, Avri Altman wrote:
> > HPB support is comprised of 4 main duties:
> > 1) Read the device HPB configuration
> > 2) Attend the device's recommendations that are embedded in the sense
> buffer
> > 3) L2P cache management - This entails sending 2 new scsi commands
> (opcodes were taken from the vendor pool):
> > a. HPB-READ-BUFFER - read L2P physical addresses for a subregion
> > b. HPB-WRITE-BUFFER - notify the device that a region is inactive (in
> host-managed mode)
> > 4) Use HPB-READ: a 3rd new scsi command (again - uses the vendor pool)
> to perform read operation instead of READ10. HPB-READ carries both the
> logical and the physical addresses.
> >
> > I will let Bean defend the Samsung approach of using a single LLD to attend
> all 4 duties.
> >
> > Another approach might be to split those duties between 2 modules:
> > - A LLD that will perform the first 2 - those can be done only using ufs
> privet stuff, and
> > - another module in scsi mid-layer that will be responsible of L2P cache
> management,
> > and HPB-READ command setup.
> > A framework to host the scsi mid-layer module can be the scsi device
> handler.
> >
> > The scsi-device-handler infrastructure was added to the kernel mainly to
> facilitate multiple paths for storage devices.
> > The HPB framework, although far from the original intention of the
> authors, might as well fit in.
> > In that sense, using READs and HPB_READs intermittently, can be perceived
> as a multi-path.
> >
> > Scsi device handlers are also attached to a specific scsi_device (lun).
> > This can serve as the glue linking between the ufs LLD and the device
> handler which resides in the scsi level.
> >
> > Device handlers comes with a rich and handy set of APIs & ops, which we
> can use to support HPB.
> > Specifically we can use it to attach & activate the device handler,
> > only after the ufs driver verified that HPB is supported by both the platform
> and the device.
> >
> > The 2 modules can communicate using the handler_data opaque pointer,
> > and the handler’s set_params op-mode: which is an open protocol
> essentially,
> > and we can use it to pass the sense buffer in its full or just a parsed version.
> >
> > Being a scsi mid-layer module, it will not break anything while sending
> > HPB-READ-BUFFER and HPB-WRITE-BUFFER as part of the L2P cache
> management duties.
> >
> > Last but not least, the device handler is already hooked in the scsi
> command setup flow - scsi_setup_fs_cmnd(),
> > So we get the hook into HPB-READ prep_fn for free.
> >
> > Later on, we might want to export the L2P cache management logic to
> user-space.
> > Locating the L2P cache management in scsi mid-layer will enable us to do
> so, using the scsi-netlink or some other means.
>
> Hi Avri,
>
> I'm not sure that I agree that HPB can be perceived as multi-path.
> Anyway, the above approach sounds interesting to me. A few questions
> though:
> - The only in-tree caller of scsi_dh_attach() I am aware of exists in
> the dm-mpath driver. I think that call is triggered by multipathd.
> I don't think that it is acceptable to require that multipathd is
> running to use the UFS HPB functionality. What is the plan for
> attaching the UFS device handler to UFS devices?
Right.
Device handlers are meant to be called as part of the device mapper
multi-path code. We can’t do that – we need to attach & activate the
device handler manually, only after the ufs driver verified that HPB is
supported by both the platform and the device.
I was thinking to rely on the ufs's 2-phase boot:
The ufs boot process is essentially comprised of 2 parts: first a
handshake with the device, and then, scsi scans and assign a scsi device
to each lun. The latter, although running a-synchronically, is
happening right after reading the device configuration - lun by lun.
By now we've read the device HPB configuration, and we are ready to
attach a scsi device to our HPB luns. A perfect timing might be while
scsi is performing its .slave_alloc() or .slave_configure().
It will require however, to include <scsi/scsi_dh.h> and "../scsi_priv.h" in ufshpb.c,
Not sure if this is acceptable.
> - Will preparing a SCSI command involve executing a SCSI command? If so,
> how will it be prevented that execution of that internally submitted
> SCSI command triggers a deadlock due to tag exhaustion?
Not sure what deadlock are you referring to.
Executing HPB-READ-BUFFER is not part of the data path,
And should not happen too often.
Anyway it can wait for a tag to become free.
Same goes to HPB-WRITE-BUFFER.
>
> Thanks,
>
> Bart.
