Data compression support in host storage controller

Abstract

Aspects relate to enabling data compression at a host storage controller coupled to a data storage device. The host storage controller can be configured to receive a request from a processing device to write / read data to / from the data storage device. The request can indicate a compression / decompression algorithm for the host storage controller to use in compressing / decompressing the data to produce compressed / decompressed data. The host storage controller can further send a command (e.g., write / read command) to the data storage device to write / read the compressed data.

Description

DATA COMPRESSION SUPPORT IN HOST STORAGE CONTROLLERTECHNICAL FIELD

[0001] The technology discussed below relates generally to data storage devices, and more particularly, to data compression for data storage devices. INTRODUCTION

[0002] Data storage devices (DSDs) -such as non-volatile memories (NVMs) -are utilized in a wide variety of devices in stationary and mobile computing environments. Examples of such devices include desktop computers, portable notebook computers, tablets, portable hard disk drives, mobile devices, cellular phones, portable media players, wearable devices, etc. Example of NMVs include Universal Flash Storage (UFS) devices, raw NAND devices, and Embedded MultiMediaCard (eMMC) devices. UFS, raw NAND, and eMMC devices are commonly used as primary data storage or boot storage in mobile devices (e.g., mobile phones, smartphones, tablets, vehicles, portable computers, etc. ) because these devices can provide high performance and low power storage memory. BRIEF SUMMARY OF SOME EXAMPLES

[0003] The following presents a summary of one or more aspects of the present disclosure, in order to provide a basic understanding of such aspects. This summary is not an extensive overview of all contemplated features of the disclosure, and is intended neither to identify key or critical elements of all aspects of the disclosure nor to delineate the scope of any or all aspects of the disclosure. Its sole purpose is to present some concepts of one or more aspects of the disclosure in a form as a prelude to the more detailed description that is presented later.

[0004] In one example, an apparatus at a host is provided that includes a processing device configured to generate a request to write data to a data storage device and a host storage controller coupled to the processing device and the data storage device and configured to receive the request from the processing device. The request further indicates a compression algorithm of a plurality of compression algorithms maintained at the host storage controller. The host storage controller is further configured to compress the data using the compression algorithm to produce compressed data and send a write command to the data storage device to write the compressed data to the data storage device.

[0005] Another example provides a method operable at a host storage controller. The method includes receiving a request from a processing device to write data to a data storage device, where the request further indicates a compression algorithm of a plurality of compression algorithms maintained at the host storage controller. The method further includes compressing the data using the compression algorithm to produce compressed data and sending a write command to the data storage device to write the compressed data to the data storage device.

[0006] Another example provides a host including means for receiving a request from a processing device to write data to a data storage device, where the request further indicates a compression algorithm of a plurality of compression algorithms maintained at the host storage controller. The host further includes means for compressing the data using the compression algorithm to produce compressed data and means for sending a write command to the data storage device to write the compressed data to the data storage device.

[0007] These and other aspects will become more fully understood upon a review of the detailed description, which follows. Other aspects, features, and examples will become apparent to those of ordinary skill in the art upon reviewing the following description of specific exemplary aspects in conjunction with the accompanying figures. While features may be discussed relative to certain examples and figures below, all examples can include one or more of the features discussed herein. In other words, while one or more examples may be discussed as having certain features, one or more of such features may also be used in accordance with the various examples discussed herein. Similarly, while examples may be discussed below as device, system, or method examples, it should be understood that such examples can be implemented in various devices, systems, and methods.BRIEF DESCRIPTION OF THE DRAWINGS

[0008] FIG. 1 is a diagram depicting an apparatus employing a data storage device according to some aspects.

[0009] FIG. 2 is a diagram illustrating an apparatus including a Universal Flash Storage (UFS) system in accordance with some aspects of the disclosure.

[0010] FIG. 3 is a diagram illustrating an example of communication between a host and a data storage device according to some aspects.

[0011] FIG. 4 is a diagram illustrating an example of data compression at a host storage controller according to some aspects.

[0012] FIG. 5 is a diagram illustrating an example of a write operation with data compression at the host storage controller according to some aspects.

[0013] FIG. 6 is a diagram illustrating an example of a read operation with data decompression at the host storage controller according to some aspects.

[0014] FIG. 7 is a diagram illustrating a transfer request configured to enable data compression or data decompression at the host storage controller according to some aspects.

[0015] FIG. 8 is a diagram illustrating an example of a command configured to enable data compression / decompression at the host storage controller according to some aspects.

[0016] FIG. 9 is a diagram illustrating an example of a write command configured to indicate data compression at the host storage controller according to some aspects.

[0017] FIG. 10 is a diagram illustrating an example of a read command configured to indicate data decompression at the host storage controller according to some aspects.

[0018] FIG. 11 is a diagram illustrating an example of a response supporting data compression / decompression at the host storage controller according to some aspects.

[0019] FIG. 12 is a flow chart illustrating an exemplary process for data compression at a host storage controller according to some aspects.

[0020] FIG. 13 is a flow chart illustrating an exemplary process for data decompression at a host storage controller according to some aspects.DETAILED DESCRIPTION

[0021] The detailed description set forth below in connection with the appended drawings is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form in order to avoid obscuring such concepts.

[0022] Several aspects of the invention will now be presented with reference to various apparatus and methods. These apparatus and methods will be described in the following detailed description and illustrated in the accompanying drawings by various blocks, modules, components, circuits, steps, processes, algorithms, etc. (collectively referred to as “elements” ) . These elements may be implemented using electronic hardware, computer software, firmware, or any combination thereof. Whether such elements are implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system.

[0023] While aspects and examples are described in this application by illustration to some examples, those skilled in the art will understand that additional implementations and use cases may come about in many different arrangements and scenarios. Innovations described herein may be implemented across many differing platform types, devices, systems, shapes, sizes, and packaging arrangements. For example, aspects and / or uses may come about via integrated chip examples and other non-module-component-based devices (e.g., end-user devices, vehicles, communication devices, computing devices, industrial equipment, retail / purchasing devices, medical devices, artificial intelligence (AI) -enabled devices, etc. ) . While some examples may or may not be specifically directed to use cases or applications, a wide assortment of applicability of described innovations may occur. Implementations may range in spectrum from chip-level or modular components to non-modular, non-chip-level implementations and further to aggregate, distributed, or original equipment manufacturer (OEM) devices or systems incorporating one or more aspects of the described innovations. In some practical settings, devices incorporating described aspects and features may also necessarily include additional components and features for the implementation and practice of described examples. It is intended that innovations described herein may be practiced in a wide variety of devices, chip-level components, systems, distributed arrangements, end-user devices, etc., of varying sizes, shapes, and constitution.

[0024] An apparatus, such as a mobile device, internet of things (IoT) device, or automotive product, may include a storage system including a host and a data storage device connected via an interface (e.g., a data link) . The data storage device may include, for example, a non-volatile memory (NVM) or solid state device (SSD) , such as a UFS device, raw NAND device, or eMMC device. The host may include, for example, a host storage controller (e.g., hardware, such as a processing unit) managed by a storage driver (e.g., UFS, NAND, or eMMC driver) . The storage driver includes software executed by, for example, a central processing unit (CPU) of the apparatus. The CPU is further controlled by an operating system (OS) having instructions executable by the CPU.

[0025] As the size of data files increases (e.g., with artificial intelligence and other applications involving files in the 10s of Gigabits (GBs) ) , data storage devices, such as UFS, raw NAND and eMMC, may suffer from performance limitations that are impacted by such large file sizes. To improve the storage performance (e.g., read / write performance) , data compression can be performed at the host to reduce the size of data transferred between the host and the device. In conventional data storage systems, data compression is performed in host software (e.g., OS kernel) . However, if an apparatus includes multiple OSs, one or more of the OSs may not support data compression. In addition, each OS that does support data compression may execute separate data compression algorithms, which increases the storage and processing requirements of the apparatus.

[0026] In various aspects of the disclosure, to improve the performance and increase the lifespan of data storage systems, data compression at the host storage controller can be supported. By performing data compression at the host storage controller, instead of in software, the data compression speed can also be increased. In some examples, the host storage controller can maintain a plurality of different compression / decompression algorithms for compressing / decompressing data of different types (e.g., object / text files, video files, audio files, etc. ) . The host storage controller can be configured to receive a request from a processing device (e.g., executing an OS) to write or read data to or from the data storage device. The request can indicate a compression / decompression algorithm for the host storage controller to use in compressing / decompressing the data to produce compressed / decompressed data. In some examples, the request can include a flag indicating to compress / decompress the data. In some examples, the request can include an algorithm identifier of the compression / decompression algorithm selected (e.g., by the processing device) for compression / decompression of the data.

[0027] In examples in which the request is a write request, the write request may include an actual size of the data to be written. In this example, after data compression, the host storage controller can send a command (e.g., a write command) to the data storage device to write the compressed data to the data storage device. The write command may include, for example, a compressed data size of the compressed data to be written to the data storage device. In examples in which the request is a read request, the read request may include an actual size of the requested data (e.g., as decompressed) and a compressed data size of compressed data corresponding to the requested data stored in the data storage device. In this example, the host storage controller can send a command (e.g., read command) to the data storage device to read the compressed data from the data storage device. The read command may include, for example, the compressed data size of the compressed data.

[0028] In some examples, the host storage controller may further be configured to receive a response from the data storage device indicating success or failure of the read or write operation on the data storage device. In some examples, the host storage controller may further be configured to send a response to the processing device indicating success or failure of the read or write operation. In examples in which the request is a write request, the response sent to the processing device may include a compressed data size of the compressed data. In examples in which the request is a read request, the response sent to the processing device may include the actual data size of the requested data.

[0029] In some examples, the host storage controller may include a plurality of data compression engines configured to operate in parallel. The host storage controller can select one of the data compression engines to compress / decompress the data using the selected compression / decompression algorithm. By providing multiple inline data compression engines, multiple read / write requests may be processed in parallel, thus increasing the speed of data compression / decompression.

[0030] FIG. 1 is a diagram depicting an apparatus employing a data storage device according to some aspects. In one example, the apparatus 100 may include a radio communication device that communicates through a radio frequency (RF) communications transceiver 116 and antenna 118 with a radio access network (RAN) , a core access network, the Internet and / or another network. In other examples, the apparatus 100 may include other types of devices, including, for example, IoT devices or automotive products, which may or may not include the transceiver 116 and / or antenna 118.

[0031] The apparatus 100 may further include a central processing unit (CPU) 102, one or more neural signal processors (NSPs) 104, and one or more graphics processing units (GPUs) 106, which may be implemented, for example, on a system-on-chip (SoC) . In an example, the CPU 102 may include a processor 110 and memory 114 (e.g., L1 and / or L2 caches or registers or RAM) , and may be controlled by an operating system 112 that is loaded from internal or external storage as data and instructions that are executable by the processor 110. The apparatus 100 may further include or access a data storage device (DSD) 108, such as a Universal Flash Storage (UFS) device, raw NAND device, eMMC device, or other non-volatile memory (NVM) device. The DSD 108 can be used to maintain data, operational parameters, and other information used to configure and operate the apparatus 100. The CPU 102 may also be operably coupled to internal and / or external devices such as a display / user interface 124, operator controls, such as buttons 126, 128, and other components.

[0032] A data communication interface (e.g., bus) 120 may be provided to support communication between the CPU 102, NSP 104, GPU 106, and / or one or more peripherals (not shown) . The data communication interface 120 may be operated in accordance with standard protocols defined for interconnecting certain components of mobile devices. For example, there may be multiple types of interfaces defined for communications between CPU 102, a user interface, displays, and camera components of a device. In addition, a link 122 may be provided to support communication between the CPU 102, the DSD 108, and various other components, such as the NSP 104 and the GPU 106. For example, the link 122 may correspond to a data storage interface (e.g., UFS interface, raw NAND interface, or eMMC interface) .

[0033] FIG. 2 is a diagram depicting an apparatus including a Universal Flash Storage (UFS) system in accordance with some aspects of the disclosure. In this example, the apparatus 200 can be a computer system or a part thereof. The apparatus 200 includes one or more processors (e.g., one exemplary processor 202 shown in FIG. 2) that can be configured to perform various functions of the apparatus, including, for example, functions typically performed by portable devices such as mobile devices, tablets, portable computers, wearable devices (e.g., earbuds, headphones, etc. ) , smartwatches, and other such devices. These functions can include wireless communications with other devices (e.g., smartphones, computers, etc. ) and application specific functions. The apparatus 200 can include a data storage system for storing various data at the apparatus. In one aspect, the data storage system can be a UFS system that includes a UFS host 204 and one or more UFS devices (e.g., one exemplary UFS device 206 shown in FIG. 2) . In some examples, the UFS host 204 can be included in or implemented by the processor 202 (e.g., a CPU) .

[0034] The processor 202 can perform various functions (e.g., using software / application 208) and can communicate with the UFS host 204 using a UFS driver 220. Using the UFS driver 220, the processor 202 can communicate, control, and exchange data with the UFS host 204, for example, via a UFS host controller 212 that provides a UFS host controller interface (UFSHCI) to the processor 202. For example, the host controller 212 (e.g., the UFSHCI) can provide a set of registers that can be accessed by the processor 202 using the UFS driver 220. The UFS host controller 212 is responsible for managing the interface and data transfer between host software (e.g., application 208) and the UFS device. This can include interface management, power management, and control functions. Communication between the processor 202 (e.g., application 208 / UFS driver 220) and UFS host controller 212 is supported via a UFS Transport Protocol (UTP) layer that provides services to the higher layers (e.g., OS / application layer) and enables the exchange of UFS Protocol Information Units (UPIUs) with the UTP layer on the UFS device. For example, upon receiving a UTP request from the UFS driver 220, the host controller 212 can generate a UPIU for that request and transport the generated UPIU to the peer UTP on the UFS device. The UTP layer further provides three service access points to higher layers, including a UFS device manager service access point (UDM_SAP) to perform device level management, such as descriptor access, a UTP command service access point (UTP_CMD_SAP) to transport commands, and a UTP task management service access point (UTP_TM_SAP) to transmit task-management functions, such as abort task functions.

[0035] The UFS host 204 and UFS device 206 are connected through a UFS interface 214. For example, each of the UFS host 204 and UFS device 206 has a UFS interconnect interface 216 that transfers data and control signals between the UFS host and UFS device. The UFS interconnect interface 216 includes a UFS interconnect layer (UIC) that handles connections between the UFS host and the UFS device. The UIC can include, for example, a Mobile Industry Processor Interface  Alliance  layer configured in accordance with the Unified Protocol (UniPro) high-speed interface protocol standard and MIPI Alliance  layer configured in accordance with the M-PHY physical layer protocol standard. The UTP layer of the UFS host controller 212 can encapsulate requests from the application layer (e.g., the application 208) into the appropriate frame structure (e.g., UPIU messages) for the UIC.

[0036] The UFS driver 220 can use a combination of registers and transfer request descriptors in system memory 210 (e.g., one or more memories (e.g., random access memory) ) to communicate with host controller hardware. In some examples, the UFS device 206 can be a memory card, an embedded bootable mass storage device, an input-output (IO) device, etc. In some aspects, the UFS device 206 includes a device controller 218 (e.g., a CPU or other processor or processing unit) and a data storage 222 that can include a non-volatile memory (NVM) for storing data. In one example, the NVM may be NAND Flash memory or the like. However, the UFS device 206 is not limited to using only NAND Flash and can use other types of NVM. The device controller 218 is configured to perform the same tasks as the UFS host controller 212 along with other device level functions, and to manage the flow of data to and from the data storage 222.

[0037] In some aspects, some or all of the functions described herein can be performed by the apparatus 200 using the processor 202, UFS host 204, and / or UFS device 206. In some examples, the processor 202, UFS host 204, and UFS device 206 may each include a microprocessor, a microcontroller, an embedded controller, a logic circuit, software, firmware, ASIC, or any kind of processing device, for performing one or more of the functions described herein as being performed by the apparatus 200.

[0038] FIG. 3 is a diagram illustrating an example of communication between a host 302 and a data storage device (device) 304 according to some aspects. In some examples, the host 302 may be a UFS host and the device 304 may be a UFS device implemented on an apparatus (e.g., a mobile device, IoT device, or automotive device) . The host 302 includes a processing device 306, a host controller 312, and an interconnect circuit 314. The processing device 306 may include one or more application clients 308 and a UFS driver 310 that may be executed by the processing device 306. In some examples, the processing device 306 corresponds to a CPU and the one or more application clients 308 correspond to host applications (e.g., OSs or other applications) . The UFS driver 310 may be configured to support UFS native command sets and / or small computer system interface (SCSI) command sets based on the SCSI architecture model (SAM) . In some examples, the UFS driver 310 may be configured to receive requests (e.g., UFS native commands or SCSI commands) from one or more application clients 308 and to generate UTP requests based on the received commands. Examples of SCSI commands may include, but are not limited to Read, Write, Read Capacity, Report LUNS, Test Unit Ready, Start Stop Unit, Inquiry, etc. . The UFS driver 310 may further be configured to send the UTP requests to the device 304 via the host controller 312 and interconnect circuits 314 and 318 (e.g., UniPro ports) on the host 302 and device 304, respectively, and a link 316 (e.g., a communication link, such as a UFS link or other non-volatile storage link) between the host 302 and the device 304. The UTP requests may be formatted into UFS Protocol Information Units (UPIUs) at the host controller 312. At the interconnect circuit 314, the UniPro layer may divide its transactions into UniPro messages that contain one or more UPIUs.

[0039] The device 304 may include a device manager 320, a plurality of logical units (LUs) 322 (e.g., LU-0 …LU-N) , device configuration information 328, and main storage 324 (e.g., non-volatile storage) , which may include, for example, a plurality of storage units 326. Each LU 322 is an independent and separately, externally addressable processing entity that processes tasks (e.g., commands (e.g., read, write, etc. )) and performs other task management functions. An LU 322 may be configured by allocating an amount of physical memory (e.g., DDR / DRAM and / or storage unit (s) 324) to the LU 322 and allocating processing capabilities to the LU 322. One or more of the LUs 322 may be well known logical units (WKLUs) that support specific types of commands and for specific UFS functions.

[0040] The device manager 320 performs device level functions (e.g., power management) and controls operations of the device 304 using the configuration information 328. The device manager 320 and logical units 322 may be implemented, for example, by a controller (e.g., controller 218 shown in FIG. 2) that may include, for example, one or more processors. The configuration information 328 may include, for example, descriptors, flags, and attributes of the device 304 that define and control specifics of the device, such as operating characteristics, interfaces, number of LUs 322, operating speeds, power profiles, etc. During device initialization (bootup) , the host 302 discovers a set of the configuration information 328 by reading various descriptors, flags, and attributes from the device 304. For example, the host 302 may exchange UPIU Query Request (Read) commands and UPIU Query Responses with the device 304 to read the descriptors, flags, and attributes from the device 304.

[0041] For artificial intelligence (AI) applications and other types of applications, data file sizes may be in the 10s of gigabits (GBs) . The large file size impacts the loading time of AI data from the UFS device 304. Since the loading time of AI data may be critical for AI applications, increasing the loading rate can improve the performance of AI applications on UFS systems.

[0042] Other types of data storage devices, such as raw NAND and eMMC, may also suffer from performance limitations that are impacted by large file sizes. For example, the read / write performance of raw NAND devices may generally be less due to the low interface speed (e.g., 18 MB / s) of raw NAND devices. This read / write performance may be further impacted as the file size increases. In addition, raw NAND and eMMC devices may be limited in the number of program / erase (P / E) cycles. Thus, the higher numbers of write operations for larger file sizes may increase the number of P / E cycles, which may in turn impact the lifespan of these devices.

[0043] Therefore, to improve the storage performance (e.g., read / write performance) and increase the lifespan of data storage devices, data compression can be performed at the host to reduce the size of data transferred between the host and the device. Implementing data compression can further improve the boot key performance indicators (KPIs) , along with the user experience. Moreover, for certain use cases, such as automotive and IoT, where the NAND memory size may be limited, data compression can increase the memory availability, thus enabling the host software to run a wide range of applications that require more memory.

[0044] In conventional data storage systems, data compression is performed in host software (e.g., OS kernel) . However, if an apparatus includes multiple OS kernels (e.g., Unified Extensible Firmware Interface (UEFI) , Manycore Platform Software Stack (MPSS) , Linux, Extensible Binding Language (XBL) , etc. ) , one or more of the OS kernels may not support data compression. In addition, each OS kernel that does support data compression must execute separate data compression algorithms, which increases the storage and processing requirements of the apparatus.

[0045] Thus, in various aspects, data compression can be performed at the host storage controller (e.g., host controller 312) . Data compression in hardware (e.g., at the host storage controller) is faster than software-based data compression, thereby improving throughput of the apparatus. In addition, by implementing data compression in the host storage controller, the storage performance may further be improved as the compression can be performed irrespective of the software / OS kernel.

[0046] FIG. 4 is a diagram illustrating an example of data compression at a host storage controller according to some aspects. In the example shown in FIG. 4, the host storage controller 402 (e.g., UFS controller, NAND controller, or eMMC controller) is coupled to a data storage device 404 (e.g., UFS device, raw NAND device, or eMMC device) via a data link 406. The host controller 402 includes a request manager 408 configured to receive and process transfer requests (e.g., read / write requests) from a storage stack 416 in software.

[0047] The host storage controller 402 can further include one or more compression / decompression engines 410 (referred to as a compression engine herein) , each configured to compress / decompress data using a compression / decompression algorithm 412 (referred to as a compression algorithm herein) maintained in the host controller 402 (e.g., stored within the host storage controller 402) . In some examples, the host storage controller 402 can include multiple inline compression engines 410, as shown in FIG. 4, to enable simultaneous parallel compression / decompression for multiple transfer requests. The number of compression engines 410 may depend, for example, on the hardware compression / decompression speed. For example, the higher the speed, the fewer number of compression engines 410 may be included. In some examples, the host controller 402 can implement multiple standard compression algorithms 412. For example, the host controller 402 may maintain LZ77, ZSTD, bzip2 and / or other suitable compression algorithm for text files or object files, MP3, AAC, FLAC, and / or other suitable compression algorithm for audio files, and AVD, HEVC, and / or other suitable compression algorithm for video files.

[0048] The storage stack 416 may be executed, for example, by a processing device 414 (which may correspond, for example, to the processor 202 shown in FIG. 2 or processing device 306 shown in FIG. 3) and may include, for example, a FileSystem layer 418, a block / unsorted block images (UBI) layer 420, a SCSI / memory technology device (MTD) layer 422, and a storage driver 424 (e.g., UFS driver or other line driver) . The FileSystem layer 418 may be, for example, part of the OS kernel (e.g., Linux kernel or other OS kernel) that has the complete information on the layout of the data storage device 404 and translates requests from all applications into logical block addresses. The block / UBI layer 420 may perform, for example, scheduling, merging, and sorting of transfer requests. The block / UBI layer 420 may correspond to a block layer for UFS and eMMC or a UBI layer for raw NAND. The SCSI / MTD layer 422 is configured to provide an interface between the storage driver 424 and upper layers using a standard set of protocols and commands and may perform, for example, error handling. The SCSI / MTD layer 422 may correspond to an SCSI layer for UFS and an MTD layer for raw NAND. For eMMC data storage devices, the SCIS / MTD layer 422 may be excluded.

[0049] The storage stack 416 is configured to send a transfer request (e.g., UTP transfer request corresponding to a read or write request) to the host controller 402. The transfer request can include, for example, an indication of a compression algorithm 412 to use for compressing or decompressing data associated with the transfer request. The compression algorithm 412 may be selected, for example, by the OS / application (e.g., the processing device 202 / 306) based on the data-pattern of the data associated with the transfer request. In some examples, the transfer request may further include a flag indicating that the data associated with the transfer request is to be compressed or decompressed.

[0050] The request manager 408 in the host controller 402 is configured to select the compression algorithm 412 indicated in the transfer request and to provide the data associated with the transfer request to a compression engine 410 for compression or decompression thereof using the selected compression algorithm 412. For example, if the transfer request is a write request that includes data to be compressed, the request manager 408 can select the compression algorithm 412 indicated in the transfer request, provide the data to the compression engine 410 for compression of the data using the selected compression algorithm 412 to produce compressed data, and then send a write command to the data storage device 404 to write the compressed data thereto. In some examples, the request manager 408 may retrieve the data to be compressed from host system memory (e.g., DDR) .

[0051] As another example, if the transfer request is a read request to read data from the data storage device 404, the request manager 408 can send a read command to the data storage device 404 to read compressed data corresponding to the requested data from the data storage device 404. The transfer manager can then select the compression (decompression) algorithm 412 indicated in the transfer request and provide the compressed data to the compression engine 410 for decompression of the compressed data using the selected decompression algorithm 412 to produce the requested data (e.g., decompressed data) . The request manager 408 can then provide the requested data to the processing device 414 (e.g., via the storage stack 416) .

[0052] FIG. 5 is a diagram illustrating an example of a write operation with data compression at the host storage controller according to some aspects. FIG. 5 illustrates the various software stack layers (e.g., FileSystem 502, Block / UBI 504, SCSI / MTD 506, and Storage Driver 508) at a host configured to write data to a Data Storage Device 512 via a host Storage Controller 510. The FileSystem layer 502, Block / UBI layer 504, SCSI / MTD layer 506, and Storage Driver layer 508 may correspond, for example, to layers within a UFS system, raw NAND system, or eMMC system.

[0053] At 514, the FileSystem layer 502 may translate a write request from an application (e.g., OS or other application) to a FileSystem write request (e.g., FS_write) . The FS_write may include an address (e.g., logical address) for writing data to the data storage device 512, a size of the data to be written to the Data Storage Device 512, and a flag indicating to compress the data to be written to the Data Storage Device 512. At 516, the Block / UBI layer 504 translates the FS_write to a Block / UBI_write, including the address, size and compression flag. Similarly, at 518, the SCSI / MTD layer 506 translates the Block / UBI_write to a SCSI / MTD_write, including the address, size, and compression flag. At 520, the Storage Driver formats the SCSI / MTD_write into a Driver, including the address, size, and compression flag, and sends the Driver_write to the host Storage Controller 510. In UFS systems, the Driver_write may correspond, for example, to a UTP transfer request.

[0054] At 522, the Storage Controller 510 compresses the data to produce compressed data at a compressed size (nSize) based on the address of the data and the original data size. The Storage Controller 510 may compress the data using an available compression algorithm maintained at the Storage Controller 510. In some examples, the write request may indicate the compression algorithm to use to compress the data. For example, the FS_write, Block / UBI_write, SCSI / MTD_write, and Driver_write may each include an algorithm identifier that identifies the compression algorithm. In some examples, the compression algorithm may be selected by the application that originated the write request based on the type of data (e.g., text / object files, audio files, video files, etc. ) .

[0055] At 524, the Storage Controller 510 can send a write command to the Data Storage Device 512 to write the compressed data thereto. The write command may indicate the compressed data size (nSize) of the compressed data, along with a buffer for writing the data. At 526, the Data Storage Device 512 may send a response to the Storage Controller 510 indicating, for example, success or failure of the write command. In the example shown in FIG. 5, the response indicates success of the write command. Therefore, at 528, 530, 532, and 534, the Storage Controller 510 returns the compressed size (nSize) of the successfully stored compressed data to the FileSystem layer 502 via the Storage Driver 508, SCSI / MTD layer 506, and Block / UBI layers 504. The compressed size is maintained at the host to enable later reading of the data from the Data Storage Device 512.

[0056] FIG. 6 is a diagram illustrating an example of a read operation with data decompression at the host storage controller according to some aspects. FIG. 6 illustrates the various software stack layers (e.g., FileSystem 602, Block / UBI 604, SCSI / MTD 606, and Storage Driver 608) at a host configured to read data from a Data Storage Device 612 via a host Storage Controller 610. The FileSystem layer 602, Block / UBI layer 604, SCSI / MTD layer 606, and Storage Driver layer 608 may correspond, for example, to layers within a UFS system, raw NAND system, or eMMC system.

[0057] At 614, the FileSystem layer 602 may translate a read request from an application (e.g., OS or other application) to a FileSystem read request (e.g., FS_read) . The FS_read may include an address (e.g., logical block address) for reading data from the data storage device 612, an original (decompressed) size of the data to be read from the Data Storage Device 612, a compressed size (nSize) of the data to be read from the Data Storage Device 612, and a flag indicating to decompress the data to be read from the Data Storage Device 612. At 616, the Block / UBI layer 604 translates the FS_read to a Block / UBI_read, including the address, size, compressed size, and decompression flag. Similarly, at 618, the SCSI / MTD layer 606 translates the Block / UBI_read to a SCSI / MTD_read, including the address, size, compressed size, and decompression flag. At 620, the Storage Driver formats the SCSI / MTD_read into a Driver, including the address, size, compressed size, and decompression flag, and sends the Driver_read to the host Storage Controller 610. In UFS systems, the Driver_read may correspond, for example, to a UTP transfer request.

[0058] At 622, the Storage Controller 610 can send a read command to the Data Storage Device 612 to read the compressed data therefrom. The read command may indicate the compressed data size (nSize) of the compressed data to be read from the Data Storage Device 612. At 624, the Data Storage Device 612 may send a response to the Storage Controller 610 indicating, for example, success or failure of the read command. In the example shown in FIG. 6, the response indicates success of the read command and includes the compressed data read from the Data Storage Device 512.

[0059] At 626, the Storage Controller 610 decompresses the data to produce decompressed data at the original size (Size) based on the address of the data and the compressed data size. The Storage Controller 610 may decompress the data using an available compression algorithm maintained at the Storage Controller 610. In some examples, the read request may indicate the compression algorithm to use to decompress the data. For example, the FS_read, Block / UBI_read, SCSI / MTD_read, and Driver_read may each include an algorithm identifier that identifies the decompression algorithm. In some examples, the decompression algorithm may be selected by the application that originated the read request based on the type of data (e.g., text / object files, audio files, video files, etc. ) . At 628, 630, 632, and 634, the Storage Controller 610 returns the original size (Size) of the successfully read and decompressed data to the FileSystem layer 602 via the Storage Driver 608, SCSI / MTD layer 606, and Block / UBI layers 604.

[0060] FIG. 7 is a diagram illustrating a transfer request configured to enable data compression or data decompression at the host storage controller according to some aspects. In the example shown in FIG. 7, the transfer request 702 is a UTP transfer request including eight data words (Dwords or DWs) . It should be understood that a data word is a standard unit of data. The UTP transfer request 702 includes a compression / decompression (C / D) bit 704 that indicates whether to enable compression / decompression at the host storage controller. In addition, the UTP transfer request 700 includes a field containing an algorithm identifier (ID) 706 that indicates a compression / decompression algorithm to use for compression / decompression at the host storage controller. The algorithm ID 706 may be selected, for example, from a table 708 maintained at the host of compression / decompression algorithms for different file types (e.g., text files / object files, audio files, video files, etc. ) . In some examples, the C / D bit 704 and algorithm ID 706 may be included within reserved fields of the UTP transfer request 702.

[0061] FIG. 8 is a diagram illustrating an example of a command configured to enable data compression / decompression at the host storage controller according to some aspects according to some aspects. In the example shown in FIG. 8, the command is a Command UPIU 800 for communicating a command (e.g., read or write command) to a Data Storage Device. The Command UPIU 802 contains a basic UPIU header, along with additional information needed to specify a command. For example, the host storage controller can generate the Command UPIU and send the Command UPIU to the data storage device to request an SCSI command service to be performed by the data storage device. The Command UPIU 802 includes an expected data transfer length field 804 in the header thereof. The expected data transfer length field 804 contains a value that represents the number of bytes to be transferred (e.g., to or from the data storage device) to complete, for example, the SCSI command request as indicated in the SCSI command descriptor blocks (CDBs) of the Command UPIU. The host storage controller can update the expected data transfer length field 804 to reflect the compressed size (e.g., when the C / D bit 704 shown in FIG. 7 is set to “1” ) . For example, if software (e.g., OS / application and storage stack) is requesting 1GB of write data size with the C / D field set to “1, ” the host storage controller may compress the data to a compressed data size of 256 MB based on compression ratios and update the expected data transfer length field to 256 MB.

[0062] The CDBs of the Command UPIU 802 may contain, for example, a Write command or a Read command. Examples of Write commands and Read commands are shown in FIGs. 9 and 10. FIG. 9 is a diagram illustrating an example of a write command configured to indicate data compression at the host storage controller according to some aspects. The write command 902 may be included, for example, in a Command UPIU (as shown in FIG. 8) and may correspond, for example, to an SCSI write command. The write command 902 includes a transfer length field 904 that indicates the number of contiguous logical blocks of data to be transferred and written to the data storage device. The host storage controller can update the transfer length field 904 to indicate the compressed size of the compressed data to be transferred and written to the data storage device. Using the above example, the transfer length 904 may be updated to reflect 256 MB of data to be transferred and written to the data storage device.

[0063] FIG. 10 is a diagram illustrating an example of a read command configured to indicate data decompression at the host storage controller according to some aspects. The read command 1002 may be included, for example, in a Command UPIU (as shown in FIG. 8) and may correspond, for example, to an SCSI read command. The read command 1002 includes a transfer length field 1004 that indicates the number of contiguous logical blocks of data to be read and transferred from the data storage device. The host storage controller can update the transfer length field 1004 to indicate the compressed size of the compressed data to be read and transferred from the data storage device. Using the above example, the transfer length 1004 may be updated to reflect 256 MB of data to be read and transferred from the data storage device.

[0064] FIG. 11 is a diagram illustrating an example of a response supporting data compression / decompression at the host storage controller according to some aspects. The response shown in FIG. 11 is a Response UPIU 1102 sent from a data storage device to a host storage controller in response to receiving a command (e.g., a write command or read command in a Command UPIU) from the host storage controller. The format of the Response UPIU 1102 includes a header containing a plurality of fields, including, for example, a data segment length field 1104 containing the number of bytes in a data segment (not specifically shown in FIG. 11) of the Response UPIU 1102. The data segment length field 1104 includes the compressed size of the data written to or read from the data storage device, as the data storage device is agnostic to the compression / decompression performed at the host storage controller.

[0065] FIG. 12 is a flow chart illustrating an exemplary process 1200 for data compression at a host storage controller according to some aspects. As described below, some or all illustrated features may be omitted in a particular implementation within the scope of the present disclosure, and some illustrated features may not be required for implementation of all embodiments. In some examples, the process 1200 may be carried out by the host controller 212 shown in FIG. 2, the host controller 312 shown in FIG. 3, the host storage controller 402 shown in FIG. 4, the storage controller 510 shown in FIG. 5, and / or the storage controller 610 shown in FIG. 6. In some examples, the process 1200 may be carried out by any suitable apparatus or means for carrying out the functions or algorithm described below.

[0066] At block 1202, the process begins with receiving a request from a processing device to write data to a data storage device, where the request further indicates a compression algorithm of a plurality of compression algorithms maintained at the host storage controller. In some examples, the request further includes a flag indicating to compress the data. In some examples, the request further includes a field including an algorithm identifier of the compression algorithm.

[0067] At block 1204, the process continues with compressing the data using the compression algorithm to produce compressed data. In some examples, the process includes compressing the data by a compression engine of a plurality of compression engines at the host storage controller, where the plurality of compression engines are configured to operate in parallel.

[0068] At block 1206, the process continues with sending a write command to the data storage device to write the compressed data to the data storage device. In some examples, the command includes a field including a compressed data size of the compressed data. In some examples, the process further includes receiving a response from the data storage device indicating success or failure of the write command. In some examples, the process further includes sending a response to the processing device indicating success or failure of the write command, where the response includes a compressed data size of the compressed data based on the response indicating success of the write command.

[0069] FIG. 13 is a flow chart illustrating another exemplary process 1300 for data compression at a host storage controller according to some aspects. As described below, some or all illustrated features may be omitted in a particular implementation within the scope of the present disclosure, and some illustrated features may not be required for implementation of all embodiments. In some examples, the process 1300 may be carried out by the host controller 212 shown in FIG. 2, the host controller 312 shown in FIG. 3, the host storage controller 402 shown in FIG. 4, the storage controller 510 shown in FIG. 5, and / or the storage controller 610 shown in FIG. 6. In some examples, the process 1300 may be carried out by any suitable apparatus or means for carrying out the functions or algorithm described below.

[0070] At block 1302, the process begins with receiving a request from a processing device to read data from a data storage device, where the request indicates a decompression algorithm of a plurality of decompression algorithms maintained at the host storage controller. In some examples, the request includes a flag indicating to decompress compressed data corresponding to the requested data. In some examples, the request includes a field including an algorithm identifier of the decompression algorithm. In some examples, the request includes an actual data size of the requested data and a compressed data size of the compressed data.

[0071] At block 1304, the process continues with sending a read command to the data storage device to read compressed data corresponding to the data from the data storage device. In some examples the read command includes a field including the compressed data size of the compressed data.

[0072] At block 1306, the process continues with receiving the compressed data corresponding to the data from the data storage device. At block 1308, the process continues with decompressing the compressed data using the decompression algorithm to produce the requested data. In some examples, the process may further include sending a response including the requested data to the processing device. The response may include, for example, an actual data size of the requested data.

[0073] In one configuration, an apparatus includes means for receiving a request from a processing device to write data to a data storage device, wherein the request further indicates a compression algorithm of a plurality of compression algorithms maintained at the host storage controller, means for compressing the data using the compression algorithm to produce compressed data, and means for sending a write command to the data storage device to write the compressed data to the data storage device. In one aspect, the aforementioned means may be the host controller 212 shown in FIG. 2, the host controller 312 shown in FIG. 3, the host storage controller 402 shown in FIG. 4, the storage controller 510 shown in FIG. 5, and / or the storage controller 610 shown in FIG. 6 configured to perform the functions recited by the aforementioned means. In another aspect, the aforementioned means may be a circuit or any apparatus configured to perform the functions recited by the aforementioned means.

[0074] Of course, in the above examples, the host controller is merely provided as an example, and other means for carrying out the described functions may be included within various aspects of the present disclosure, including any other suitable apparatus or means described in any one of the FIGs. 1–6, and utilizing, for example, the processes and / or algorithms described herein in relation to FIGs. 5, 6, 12, and / or 13.

[0075] The following provides an overview of aspects of the present disclosure:

[0076] Aspect 1: A method operable at a host storage controller, the method comprising: receiving a request from a processing device to write data to a data storage device, wherein the request further indicates a compression algorithm of a plurality of compression algorithms maintained at the host storage controller; compressing the data using the compression algorithm to produce compressed data; and sending a write command to the data storage device to write the compressed data to the data storage device.

[0077] Aspect 2: The method of aspect 1, wherein the request further comprises a flag indicating to compress the data.

[0078] Aspect 3: The method of aspect 1 or 2, wherein the request further comprises a field including an algorithm identifier of the compression algorithm.

[0079] Aspect 4: The method of any of aspects 1 through 3, wherein the command comprises a field including a compressed data size of the compressed data.

[0080] Aspect 5: The method of any of aspects 1 through 4, further comprising: receiving a response from the data storage device indicating success or failure of the write command.

[0081] Aspect 6: The method of any of aspects 1 through 5, further comprising: sending a response to the processing device indicating success or failure of the write command, wherein the response comprises a compressed data size of the compressed data based on the response indicating success of the write command.

[0082] Aspect 7: The method of any of aspects 1 through 6, further comprising: receiving an additional request from the processing device to read additional data from the data storage device, wherein the request further indicates a decompression algorithm of a plurality of decompression algorithms maintained at the host storage controller; sending a read command to the data storage device to read additional compressed data corresponding to the additional data from the data storage device; receiving the additional compressed data corresponding to the additional data from the data storage device; and decompressing the additional compressed data using the decompression algorithm to produce the additional data.

[0083] Aspect 8: The method of aspect 7, wherein the additional request further comprises a flag indicating to decompress the additional compressed data.

[0084] Aspect 9: The method of aspect 7 or 8, wherein the additional request further comprises a field including an algorithm identifier of the decompression algorithm.

[0085] Aspect 10: The method of any of aspects 7 through 9, wherein the additional request comprises an actual data size of the additional data and a compressed data size of the additional compressed data.

[0086] Aspect 11: The method of any of aspects 7 through 10, wherein the read command comprises a field including a compressed data size of the additional compressed data.

[0087] Aspect 12: The method of any of aspects 7 through 11, further comprising: sending a response comprising the additional data to the processing device, wherein the response comprises an actual data size of the additional data.

[0088] Aspect 13: The method of any of aspects 1 through 12, wherein the compressing the data further comprises: compressing the data by a compression engine of a plurality of compression engines at the host storage controller, wherein the plurality of compression engines are configured to operate in parallel.

[0089] Aspect 14: An apparatus at a host, comprising: a processing device configured to generate a request to write data to a data storage device; and a host storage controller coupled to the processing device and the data storage device and configured to perform a method of any of aspects 1 through 13.

[0090] Aspect 15: A host comprising means for performing a method of any of aspects 1 through 13.

[0091] Within the present disclosure, the word “exemplary” is used to mean “serving as an example, instance, or illustration. ” Any implementation or aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects of the disclosure. Likewise, the term “aspects” does not require that all aspects of the disclosure include the discussed feature, advantage or mode of operation. The term “coupled” is used herein to refer to the direct or indirect coupling between two objects. For example, if object A physically touches object B, and object B touches object C, then objects A and C may still be considered coupled to one another-even if they do not directly physically touch each other. For instance, a first object may be coupled to a second object even though the first object is never directly physically in contact with the second object. The terms “circuit” and “circuitry” are used broadly, and intended to include both hardware implementations of electrical devices and conductors that, when connected and configured, enable the performance of the functions described in the present disclosure, without limitation as to the type of electronic circuits, as well as software implementations of information and instructions that, when executed by a processor, enable the performance of the functions described in the present disclosure.

[0092] One or more of the components, steps, features and / or functions illustrated in FIGs. 1–13 may be rearranged and / or combined into a single component, step, feature or function or embodied in several components, steps, or functions. Additional elements, components, steps, and / or functions may also be added without departing from novel features disclosed herein. The apparatus, devices, and / or components illustrated in FIGs. 1–6 may be configured to perform one or more of the methods, features, or steps described herein. The novel algorithms described herein may also be efficiently implemented in software and / or embedded in hardware.

[0093] Any reference to an element herein using a designation e.g., “first, ” “second, ” and so forth does not generally limit the quantity or order of those elements. Rather, these designations are used herein as a convenient way of distinguishing between two or more elements or instances of an element. Thus, a reference to first and second elements does not mean that only two elements can be employed, or that the first element must precede the second element.

[0094] It is to be understood that the specific order or hierarchy of steps in the methods disclosed is an illustration of exemplary processes. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the methods may be rearranged. The accompanying method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented unless specifically recited therein.

[0095] The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but are to be accorded the full scope consistent with the language of the claims, wherein reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more. ” Unless specifically stated otherwise, the term “some” refers to one or more. A phrase referring to “at least one of” a list of items refers to any combination of those items, including single members. As an example, “at least one of: a, b, or c” is intended to cover: a; b; c; a and b; a and c; b and c; and a, b and c. All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. No claim element is to be construed under the provisions of 35 U.S.C. §112 (f) unless the element is expressly recited using the phrase “means for” or, in the case of a method claim, the element is recited using the phrase “step for. ”

Claims

1.An apparatus at a host, comprising:a processing device configured to generate a request to write data to a data storage device; anda host storage controller coupled to the processing device and the data storage device and configured to:receive the request from the processing device, wherein the request further indicates a compression algorithm of a plurality of compression algorithms maintained at the host storage controller;compress the data using the compression algorithm to produce compressed data; andsend a write command to the data storage device to write the compressed data to the data storage device.2.The apparatus of claim 1, wherein the request further comprises a flag indicating to compress the data.3.The apparatus of claim 1, wherein the request further comprises a field including an algorithm identifier of the compression algorithm.4.The apparatus of claim 1, wherein the command comprises a field including a compressed data size of the compressed data.5.The apparatus of claim 1, wherein the host storage controller is further configured to:receive a response from the data storage device indicating success or failure of the write command.6.The apparatus of claim 1, wherein the host storage controller is further configured to:send a response to the processing device indicating success or failure of the write command, wherein the response comprises a compressed data size of the compressed data based on the response indicating success of the write command.7.The apparatus of claim 1, wherein the host storage controller is further configured to:receive an additional request from the processing device to read additional data from the data storage device, wherein the request further indicates a decompression algorithm of a plurality of decompression algorithms maintained at the host storage controller;send a read command to the data storage device to read additional compressed data corresponding to the additional data from the data storage device;receive the additional compressed data corresponding to the additional data from the data storage device; anddecompress the additional compressed data using the decompression algorithm to produce the additional data.8.The apparatus of claim 7, wherein the additional request further comprises a flag indicating to decompress the additional compressed data.9.The apparatus of claim 7, wherein the additional request further comprises a field including an algorithm identifier of the decompression algorithm.10.The apparatus of claim 7, wherein the additional request comprises an actual data size of the additional data and a compressed data size of the additional compressed data.11.The apparatus of claim 7, wherein the read command comprises a field including a compressed data size of the additional compressed data.12.The apparatus of claim 7, wherein the host storage controller is further configured to:send a response comprising the additional data to the processing device, wherein the response comprises an actual data size of the additional data.13.The apparatus of claim 1, wherein the host storage controller further comprises a plurality of compression engines configured to operate in parallel, and wherein the host storage controller is further configured to:compress the data by a compression engine of the plurality of compression engines.14.A method operable at a host storage controller, the method comprising:receiving a request from a processing device to write data to a data storage device, wherein the request further indicates a compression algorithm of a plurality of compression algorithms maintained at the host storage controller;compressing the data using the compression algorithm to produce compressed data; andsending a write command to the data storage device to write the compressed data to the data storage device.15.The method of claim 14, wherein the request further comprises a flag indicating to compress the data and a field including an algorithm identifier of the compression algorithm, wherein the command comprises a field including a compressed data size of the compressed data.16.The method of claim 14, further comprising:receiving a first response from the data storage device indicating success or failure of the write command; andsending a second response to the processing device indicating success or failure of the write command, wherein the second response comprises a compressed data size of the compressed data based on the response indicating success of the write command.17.The method of claim 14, further comprising:receiving an additional request from the processing device to read additional data from the data storage device, wherein the request further indicates a decompression algorithm of a plurality of decompression algorithms maintained at the host storage controller;sending a read command to the data storage device to read additional compressed data corresponding to the additional data from the data storage device;receiving the additional compressed data corresponding to the additional data from the data storage device; anddecompressing the additional compressed data using the decompression algorithm to produce the additional data.18.The method of claim 17, wherein the additional request further comprises a flag indicating to decompress the additional compressed data, a field including an algorithm identifier of the decompression algorithm, an actual data size of the additional data, and a compressed data size of the additional compressed data, wherein the read command comprises a field including the compressed data size of the additional compressed data.19.The method of claim 17, further comprising:sending a response comprising the additional data to the processing device, wherein the response comprises an actual data size of the additional data.20.A host, comprising:means for receiving a request from a processing device to write data to a data storage device, wherein the request further indicates a compression algorithm of a plurality of compression algorithms maintained at the host;means for compressing the data using the compression algorithm to produce compressed data; andmeans for sending a write command to the data storage device to write the compressed data to the data storage device.

Images