lkml.org 
[lkml]   [2020]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH v2 5/5] scsi: ufs: UFS Host Performance Booster(HPB) driver
    From
    Date
    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?
    - 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?

    Thanks,

    Bart.

    \
     
     \ /
      Last update: 2020-04-28 05:37    [W:4.200 / U:1.276 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site