Decompression implementation method and device for DPU accelerator card based on heterogeneous architecture

Abstract

The invention provides a decompression implementation method and device based on a DPU acceleration card under a heterogeneous architecture, and the method comprises the steps: receiving a compressed data stream unloaded by a CPU server through an established connection by the DPU acceleration card, and storing the compressed data stream to a DDR storage unit of the DPU acceleration card; sequentially reading sub-data streams with a preset byte length in the compressed data stream from the DDR storage unit into an acceleration core, and decompressing the sub-data streams by the acceleration core, comprising the following steps of: comparing and searching an initial position of a compressed file in the sub-data streams by utilizing a sliding window mode; for the compressed blocks forming the compressed file, analyzing according to a preset decompression mode to obtain decompressed data contained in each compressed block in the compressed data stream; combining the decompressed data contained in each compressed block obtained by decompression into one path of original data; and after the data are decompressed by the acceleration core, writing the decompressed original data back to the DDR storage unit, and transmitting the original data back to the CPU server through the established connection.

Description

Technical Field

[0001] The present invention relates to the technical field of decoding implementation under heterogeneous architecture, and in particular to a decompression implementation method and device based on a DPU acceleration card under a heterogeneous architecture. Background Art

[0002] With the development of technology, the performance of disk reading and writing and network bandwidth has been continuously improved. The performance bottleneck in the database and big data fields has shifted to computing power, and the existing CPU solutions cannot provide sufficient computing power to support the existing big data business scale.

[0003] The shortcomings of existing decompression algorithms, such as snappy decompression, mainly include: (1) snappy decompression can only be applied to CPU scenarios and relies on the CPU server to call the decompression function. In other words, snappy decompression can only be implemented on CPU servers; (2) the CPU instruction set architecture cannot efficiently and quickly decompress a large amount of snappy compressed data; (3) the CPU decompression process will generate a high CPU occupancy rate, making the server unable to perform other tasks.

[0004] Therefore, how to use heterogeneous systems to build a more powerful decompression implementation solution is a technical problem that needs to be solved urgently. Summary of the invention

[0005] In view of this, an embodiment of the present invention provides a decompression implementation method based on a DPU acceleration card in a heterogeneous architecture to eliminate or improve one or more defects existing in the prior art.

[0006] One aspect of the present invention provides a decompression implementation method of a DPU acceleration card based on a heterogeneous architecture, wherein the DPU acceleration card is connected to a CPU server to form a heterogeneous system, and the DPU acceleration card includes a DDR storage unit and an acceleration core, and the method includes the following steps:

[0007] The DPU accelerator card receives a compressed data stream unloaded by the CPU server through an established connection, and stores the compressed data stream in a DDR storage unit of the DPU accelerator card; wherein the compressed data stream includes a compressed file, the compressed file is composed of a plurality of compressed blocks, and the compressed block carries block type information;

[0008] Reading sub-data streams of preset byte length in the compressed data stream from the DDR storage unit in sequence to the acceleration core, and decompressing the sub-data streams by the acceleration core;

[0009] Among them, the step of decompressing the sub-data stream by the acceleration core includes: using a sliding window method to compare and search for the starting position of the compressed file in the sub-data stream, and the starting position of the compressed file is identified by block type information; for the compressed blocks that constitute the compressed file, parsing according to a preset decompression method to obtain the decompressed data contained in each compressed block in the compressed data stream; merging the decompressed data contained in each compressed block obtained by decompression into one path of original data; after decompression by the acceleration core, writing the decompressed original data back to the DDR storage unit, and the original data is transmitted back to the CPU server through the established connection.

[0010] In some embodiments of the present invention, each compressed block also includes block length information and block data content, and the step of comparing and searching the starting position of the compressed file in the sub-data stream using a sliding window method includes: comparing and searching the position of the first compressed block of the compressed file in the sub-data stream using a sliding window method, thereby determining the starting position of each compressed file.

[0011] In some embodiments of the present invention, the step of parsing according to a preset decompression method to obtain decompressed data contained in each compressed block in the compressed data stream includes: using a sliding window method to parse block data content from the compressed block according to block length information, the block data content including length information and compressed data, and reading compressed data that conforms to the length information from the block data content; using a tag contained in the compressed data to decompress the decompressed data contained in a single compressed block from the compressed data.

[0012] In some embodiments of the present invention, the step of merging the decompressed data contained in each compressed block obtained by decompression into one path of original data includes: using a multiple-choice switch to merge the decompressed data contained in each compressed block obtained by decompression based on different tags into one path of original data.

[0013] In some embodiments of the present invention, the block data content further includes a cyclic redundancy check bit for detecting or checking decoding data errors; the length information included in the block data content is encoded using varint encoding rules.

[0014] In some embodiments of the present invention, the types of tags include literal tags and copy tags; the step of decompressing the decompressed data contained in a single compressed block from the compressed data using the tags contained in the compressed data includes: when the tag type is a literal tag, directly using data of a specified length in the compressed data as decompressed data; when the tag type is a copy tag, copying data of a specified length from the previous data as decompressed data according to the offset position contained in the compressed data.

[0015] In some embodiments of the present invention, the copy tag is further divided into multiple copy forms according to length information and offset position, and the copy form keyword is used to identify the compressed data; the prior data is cached through the pre-designed RAM memory, read address register and write address register on the DPU accelerator card for reading and copying.

[0016] In some embodiments of the present invention, the preset decompression mode includes any one of snappy decompression, Gzip decompression, LZ4 decompression and Brotli decompression.

[0017] Another aspect of the present invention provides a decompression implementation device based on a DPU acceleration card under a heterogeneous architecture, wherein the DPU acceleration card establishes a connection with a CPU server to form a heterogeneous system, and the DPU acceleration card includes a DDR storage unit and an acceleration core, wherein the device includes: the DDR storage unit is used to receive and store a compressed data stream unloaded by the CPU server through an established connection, and reads sub-data streams of a preset byte length in the compressed data stream from the DDR storage unit in sequence to the acceleration core, and the acceleration core decompresses the sub-data streams; wherein the compressed data stream includes a compressed file, and the compressed file is composed of a plurality of compressed blocks, and the compressed block carries a block type information; the acceleration core is used to decompress the sub-data stream, specifically including: using a sliding window method to compare and search for the starting position of the compressed file in the sub-data stream, the starting position of the compressed file is identified by the block type information; for the compressed blocks that constitute the compressed file, parsing according to a preset decompression method to obtain the decompressed data contained in each compressed block in the compressed data stream; merging the decompressed data contained in each compressed block obtained by decompression into one path of original data; the DDR storage unit is also used to write back the original data obtained after decompression by the acceleration core, and transmit the original data back to the CPU server through the established connection.

[0018] In some embodiments of the present invention, a sliding window register is pre-set in the decompression implementation device based on the DPU acceleration card under the heterogeneous architecture to accelerate the decompression processing of the sub-data stream, and the sliding window register includes: a first sliding window register, which is used to compare and find the position of the first compressed block of the compressed file in the sub-data stream by using a sliding window method, so as to determine the starting position of each compressed file; wherein each compressed block also contains block length information and block data content; a second sliding window register, which is used to parse the block data content from the compressed block according to the block length information by using a sliding window method, and the block data content contains length information and compressed data, and reads the compressed data that meets the length information from the block data content; uses the label contained in the compressed data to decompress the decompressed data contained in a single compressed block from the compressed data; a third sliding window register, which is used to merge the decompressed data contained in each compressed block obtained by decompression based on different labels into one original data by using a sliding window method and a multiple-choice switch.

[0019] The present invention discloses a decompression implementation method and device based on a DPU accelerator card in a heterogeneous architecture, which can offload the compressed data stream to be decompressed to the DPU accelerator card, and use the DPU accelerator card to gradually parse out the decompressed data contained in the compressed data stream in a sliding window manner, and integrate the original data to obtain a path as output, thereby realizing decompression from the compressed data stream to the original data in a heterogeneous system.

[0020] Additional advantages, purposes, and features of the present invention will be described in part in the following description, and will become apparent to those skilled in the art after studying the following, or may be learned from the practice of the present invention. The purposes and other advantages of the present invention may be achieved and obtained by the structures specifically indicated in the specification and the accompanying drawings.

[0021] Those skilled in the art will appreciate that the objectives and advantages that can be achieved with the present invention are not limited to the above specific description, and the above and other objectives that can be achieved by the present invention will be more clearly understood from the following detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The drawings described herein are used to provide a further understanding of the present invention, constitute a part of the present application, and do not constitute a limitation of the present invention. In the drawings:

[0023] Figure 1 The present invention is a flowchart of a method for implementing decompression based on a DPU accelerator card in a heterogeneous architecture in one embodiment of the present invention.

[0024] Figure 2 Schematic diagram of heterogeneous architecture.

[0025] Figure 3This is a diagram of the decompression implementation steps of a DPU acceleration card based on a heterogeneous architecture in one embodiment of the present invention.

[0026] Figure 4 Schematic diagram of the external interface of the acceleration core in one embodiment of the present invention.

[0027] Figure 5 FIG. 4 is a flowchart of an acceleration core processing in one embodiment of the present invention.

[0028] Figure 6 The figure is a schematic diagram of the compressed block format contained in the compressed file in one embodiment of the present invention.

[0029] Figure 7 The figure is a schematic diagram of the process of indicating the writing position of the sliding window by a pointer in one embodiment of the present invention.

[0030] Figure 8 The figure is a schematic diagram of the process of extracting and outputting data content in a compressed block in one embodiment of the present invention.

[0031] Fig. 9 Schematic diagram of the structure of data content contained in a compressed block in one embodiment of the present invention.

[0032] Fig.10 The figure is a flowchart of parsing the length information of a varint code in one embodiment of the present invention.

[0033] Fig.11 The figure is a schematic diagram of the processing sequence for parsing the length information of a varint code in one embodiment of the present invention.

[0034] Fig.12 The figure is a schematic diagram of the process of parsing varint code by splicing in one embodiment of the present invention.

[0035] Fig.13 Schematic diagram of the structure of compressed blocks with different tags in one embodiment of the present invention.

[0036] Fig.14 Schematic diagram of a write address register and a read address register in one embodiment of the present invention.

[0037] Fig.15 The figure is a schematic diagram of the principle of reading a RAM register in one embodiment of the present invention.

[0038] Fig.16 It is a schematic diagram of synthesizing a literal tag and a copied tag data into one path of original data in one embodiment of the present invention.

[0039] Fig.17 The figure is a schematic diagram showing the principle of merging multiple data channels by using a sliding window in one embodiment of the present invention. DETAILED DESCRIPTION

[0040] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the embodiments and the accompanying drawings. Here, the illustrative embodiments of the present invention and their descriptions are used to explain the present invention, but are not intended to limit the present invention.

[0041] It should also be noted that, in order to avoid obscuring the present invention due to unnecessary details, only structures and / or processing steps closely related to the solutions according to the present invention are shown in the accompanying drawings, while other details that are not closely related to the present invention are omitted.

[0042] It should be emphasized that the term “include / comprises” when used herein refers to the presence of features, elements, steps or components, but does not exclude the presence or addition of one or more other features, elements, steps or components.

[0043] It should also be noted that, unless otherwise specified, the term “connection” herein may refer not only to a direct connection but also to an indirect connection involving an intermediate.

[0044] Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings. In the accompanying drawings, the same reference numerals represent the same or similar components, or the same or similar steps.

[0045] In order to overcome the problems existing in the prior art, the present invention aims to propose a new decompression implementation method and device under a heterogeneous architecture in the field of database and big data. The solution relies on a heterogeneous computing system composed of a DPU acceleration card and a traditional CPU server to replace the existing pure CPU server, while greatly improving the decompression efficiency.

[0046] Figure 1 FIG. 1 is a flow chart of a decompression implementation method based on a DPU accelerator card in a heterogeneous architecture in one embodiment of the present invention. Figure 1 As shown, the DPU accelerator card is connected to the CPU server to form a heterogeneous system, and the DPU accelerator card includes a DDR storage unit and an acceleration core. The decompression implementation method of the DPU accelerator card based on the heterogeneous architecture proposed in the present invention includes the following steps:

[0047] Step S100: The DPU accelerator card receives a compressed data stream unloaded by the CPU server through an established connection, and stores the compressed data stream in a DDR storage unit of the DPU accelerator card; wherein the compressed data stream includes a compressed file, the compressed file consists of multiple compressed blocks, and the compressed blocks carry block type information.

[0048] Step S200: sub-data streams of preset byte length in the compressed data stream are sequentially read from the DDR storage unit to the acceleration core, and the acceleration core decompresses the sub-data streams.

[0049] Step S300: after decompression by the acceleration core, the decompressed original data is written back to the DDR storage unit, and the original data is transmitted back to the CPU server through the established connection, thereby realizing decompression from compressed data stream to original data in a heterogeneous system.

[0050] The step of accelerating the decompression of the sub-data stream in step S200 specifically includes:

[0051] Step S210: The step of accelerating the decompression of the sub-data stream includes: using a sliding window to compare and search for the starting position of the compressed file in the sub-data stream, and the starting position of the compressed file is identified by block type information.

[0052] In the specific implementation process, each compressed block also includes block length information and block data content. The step of using a sliding window to compare and search for the starting position of the compressed file in the sub-data stream in step S210 includes: using a sliding window to compare and search for the position of the first compressed block of the compressed file in the sub-data stream, thereby determining the starting position of each compressed file.

[0053] By adopting the embodiment of the invention, the position of the compressed file contained in the compressed data stream can be determined through the preset sliding window register on the DPU accelerator card, so that the compressed file can be parsed based on the preset decompression rules, thereby realizing decompression from the compressed data stream to the original data in a heterogeneous system.

[0054] Step S220: For the compressed blocks constituting the compressed file, parse according to a preset decompression method to obtain decompressed data contained in each compressed block in the compressed data stream.

[0055] In the specific implementation process, the step of parsing the decompressed data contained in each compressed block in the compressed data stream according to the preset decompression method in step S220 includes: parsing the block data content from the compressed block according to the block length information using a sliding window method, the block data content including length information and compressed data, and reading the compressed data that meets the length information from the block data content; using the tag contained in the compressed data to decompress the decompressed data contained in a single compressed block from the compressed data.

[0056] By adopting the embodiment of the invention, each compressed block contained in the compressed file can be decompressed through a sliding window register to obtain the block data content contained in the compressed block, and thus the compressed data can be parsed based on the block data content. The compressed data is generally a part of the original data, and the decompressed data obtained by decompressing each compressed block needs to be spliced ​​to obtain the original data.

[0057] Step S230: merging the decompressed data contained in each compressed block obtained by decompression into one channel of original data.

[0058] In a specific implementation process, the step of merging the decompressed data contained in each compressed block obtained by decompression into one path of original data in step S230 includes: using a multiple-choice switch to merge the decompressed data contained in each compressed block obtained by decompression based on different tags into one path of original data.

[0059] In summary, the decompression implementation method based on the DPU acceleration card in a heterogeneous architecture proposed in the present invention can offload the compressed data stream to be decompressed to the DPU acceleration card, and use the DPU acceleration card to gradually parse the decompressed data contained in the compressed data stream in a sliding window manner, and integrate it to obtain a path of original data as output, thereby realizing decompression from compressed data stream to original data in a heterogeneous system.

[0060] In some embodiments of the present invention, the block data content also includes a cyclic redundancy check bit for detecting or checking decoded data errors. The length information included in the block data content is encoded using varint encoding rules.

[0061] By adopting the embodiment of the invention, varint encoding can save storage space and improve space utilization, and there is no need to specify the length of the value, and it can adapt to integers of different sizes, so that compression and decompression can be achieved more efficiently.

[0062] In some embodiments of the present invention, the types of tags include literal tags and copy tags. The step of decompressing the decompressed data contained in a single compressed block from the compressed data using the tag contained in the compressed data included in step S230 of the present invention includes: when the tag type is a literal tag, directly using the data of a specified length in the compressed data as the decompressed data; when the tag type is a copy tag, copying the data of a specified length from the previous data according to the offset position contained in the compressed data as the decompressed data.

[0063] By adopting the embodiment of the invention, the compressed blocks of literal tags can be used to store non-repetitive information, and the compressed blocks of duplicate tags can be used to store repetitive information.

[0064] In some embodiments of the present invention, the copy tag is further divided into multiple copy forms according to the length information and the offset position, and the copy form keyword is used to identify the compressed data. In addition, the previous data is cached through the pre-designed RAM memory, read address register and write address register on the DPU accelerator card for reading and copying.

[0065] In some embodiments of the present invention, the selected decompression method includes any one of snappy decompression, Gzip decompression, LZ4 decompression and Brotli decompression. In the specification of the present invention, the snappy decompression method is mainly used as an example. Among them, snappy is an open source data compression library, the main feature of which is its high compression and decompression speed, rather than the pursuit of the ultimate compression rate. Snappy is an algorithm for fast compression and decompression of data developed by Google, which aims to provide high-speed compression and decompression speed while maintaining a high compression ratio, although this compression ratio may be relatively lower than some other algorithms.

[0066] Figure 2 The figure is a schematic diagram of a heterogeneous architecture. The CPU server and the DPU accelerator card are connected through a PCIe channel. The CPU server contains the CPU and memory, and the DPU accelerator card contains an interface for connecting to the outside world, DDR, and an acceleration core.

[0067] The overall scheme of the present invention is designed as follows: (1) The DPU acceleration card has a standard PCIe interface, which is inserted into the CPU server through a PCIe slot, and data is transmitted through PCIe. (2) Optionally, the DPU acceleration card provides a fiber optic interface, a network port, or other data transmission interface. (3) The DPU acceleration card includes a DDR storage unit and an acceleration core for calculation. (4) The data is transmitted from the CPU memory to the DDR of the DPU acceleration card through PCIe to transfer compressed data; in addition, compressed data can also be input from the outside through a fiber optic interface, a network port, or other interfaces and stored in the DDR of the DPU acceleration card. (5) The acceleration core reads the compressed data from the DPU acceleration card DDR. (6) After decompression by the acceleration core, the output decompressed data is written back to the DPU acceleration card DDR. (7) Finally, the data is transmitted back to the CPU memory through PCIe to complete the entire snappy decompression algorithm heterogeneous acceleration process. (8) In addition, multiple acceleration cores can be implemented simultaneously on a DPU acceleration card to achieve parallel decompression of compressed data input from multiple channels.

[0068] Figure 3 This is a diagram of the decompression implementation steps of a DPU accelerator card based on a heterogeneous architecture in an embodiment of the present invention. It includes the following steps:

[0069] Step S310: the server sends the compressed data to the DPU accelerator card, or (or) the compressed data is input to the DPU accelerator card through an external interface;

[0070] Step S320: the DPU accelerator card caches the input compressed data into the DDR;

[0071] Step S330: the acceleration core reads the compressed data from the DDR and decompresses it into original data;

[0072] Step S340: the acceleration core stores the decompressed raw data into the DDR;

[0073] Step S350: The server reads the decompressed original data from the DDR of the DPU acceleration card.

[0074] Figure 4 This is a schematic diagram of the external interface of the acceleration core in one embodiment of the present invention, which shows the input and output of the acceleration core. The input is compressed data (compressed data stream, or sub-data stream), and the output is original data. The process of merging multiple decompressed data is hidden here.

[0075] The snappy decompression function of the heterogeneous platform is designed to receive snappy compressed data streams, parse tag information from the compressed data stream, and parse the original data (original data is also decompressed data) from the data stream based on the tag information. The snappy decompression function is executed on the DPU accelerator card, and we call this functional module the acceleration core. In this solution, the acceleration core can be understood as different functional modules.

[0076] Figure 5 This is a flowchart of the acceleration core processing in an embodiment of the present invention. Taking Snappy decompression as an example, after the acceleration core reads data from DD4R, it first splices the data into a sliding window form, screens the first compressed block of the compressed file by comparing the 10 bytes of the frame header, and when the match is successful, decompresses the data according to the snappy rule, writes the decompressed data to DDR, splices the original data, and transmits it back to the CPU server. Figure 5 The following steps are included: step S:510, the acceleration core starts processing the data to be decompressed of the heterogeneous architecture; step S520, the acceleration core reads data from the DDR; step S530, the acceleration core splices the data into a sliding window format; step S540, determines whether the 10 bytes of the frame header match, if so, enters step S550, if not, returns to step S530; step S550, decompresses the data according to the snappy format; step S560, writes the decompressed data back to the DDR; step S570, ends the decompression processing flow under the heterogeneous architecture.

[0077] 1. In one embodiment of the present invention, the SNAPPY compression format is (compression block is represented by chunk), such as Figure 6 As shown:

[0078] 2. A compressed file consists of multiple chunks.

[0079] 3. Each chunk contains:

[0080] (1) 1 byte of chunk type (i.e., chunk type information):

[0081] ①0xFF indicates the first chunk of the file. It is only used as an identifier and has no actual decompression significance.

[0082] ②0x00 indicates a normal compressed data chunk.

[0083] (2) Length information N consisting of 3 bytes;

[0084] ①The length of the first chunk is fixed to 6;

[0085] ②The length of other chunks is determined by the compressed content.

[0086] (3) N bytes of compressed data content;

[0087] ①The compressed content of the first chunk is fixed to “sNaPpY”.

[0088] ②The compressed content of other chunks is the actual compressed data.

[0089] In the initial preparation stage of decompression, the steps include: (1) The compressed data is unloaded from the host to the DPU accelerator card. The host sends the compressed data to the DPU accelerator card DDR through the PCIe channel and starts the execution of the acceleration core. Or the compressed data is input to the DDR of the DPU accelerator card through interfaces such as optical fiber and network port, and the DPU accelerator card starts the acceleration core to perform decompression. (2) The compressed data is read from the DDR to the acceleration core. The acceleration core reads the compressed data from the DDR. The bit width of each read data is determined by the pin bit width of the DDR, and can also be customized. It can be one byte or two bytes or more bytes. We define the data bit width for reading DDR as DW (Data Width).

[0090] Figure 7 The figure is a schematic diagram of the process of indicating the writing position of the sliding window by a pointer in one embodiment of the present invention. Figure 7 The steps shown are used in the process of the acceleration core searching for the first chunk of a compressed file. First, after reading the compressed data, the acceleration core needs to detect whether it is a normal compressed file. If it is not a normal compressed file, it will not be processed. The detection method is to determine whether the first chunk is correct. As shown in 7, the first chunk is composed of "0xFF" + "0x06" + "sNaPpY", a total of 10 bytes. Since the 10 bytes of the first chunk are fixed values, in order to reduce processing time, the format of the first chunk is not parsed, but the content of the first chunk is directly judged. The judgment method adopts a sliding window method.

[0091] Here, a register with a bit width of N1 bytes is defined as a sliding window, and N1 needs to meet the following conditions: (1) sliding window width N1 ≥ DW*2. (2) sliding window width N1 ≥ 10.

[0092] At the same time, a pointer is also defined here to indicate the position where the sliding window can be written. The pointer defaults to 0, pointing to the starting position of the sliding window. When a data with a bit width of DW bytes is read from the DDR and written to the position pointed to by the pointer in the sliding window, the pointer value increases by DW. Each time the DDR is read, it is necessary to determine whether the remaining width in the sliding window can store the data content to be read next time. The requirement is "N1-pointer value ≥ DW", that is, the data read and written to the sliding window cannot overflow outside the sliding window. When the pointer value is greater than or equal to 10, it means that the sliding window may contain the data of the first chunk, so the first 10 bytes of the sliding window are compared with the data of the first chunk.

[0093] If it does not match the first chunk, the entire sliding window is shifted left by one byte and the pointer value is reduced by 1. Repeat the above steps to continue to determine whether the pointer value is greater than or equal to 10. If it is greater than or equal to 10, perform another comparison.

[0094] If it matches the first chunk, it means the starting position of the compressed file is found, and the sliding window is shifted left by 10 bytes, which is equivalent to discarding the data of the first chunk. Then the pointer value in the sliding window is determined. If the pointer value is greater than DW, the data of the first DW bytes in the sliding window is read out and sent to the subsequent module for decompression.

[0095] Through the above operations, the first chunk is compared, the starting position of the file is found, and it is ensured that the file is decompressed from the beginning.

[0096] Figure 8 The figure is a schematic diagram of the process of extracting and outputting data content in a compressed block in one embodiment of the present invention. Figure 8 The method steps shown are used in the process of unpacking compressed blocks other than the first compressed block of the accelerated verification compressed file.

[0097] Starting from the second chunk, the data is in standard compression format. Before decompression, each chunk needs to be unpacked. The packet format is: (1) one-byte chunk type. Starting from the second chunk, the chunk type is 0x00; (2) three-byte chunk length information N; (3) N bytes of chunk data content.

[0098] The design also adopts a sliding window approach, the main purpose of which is to extract N bytes of chunk data content from the chunk format and transmit it to the next module for decompression. The width of the sliding window is N2 bytes, and N2 needs to satisfy: (1) N2 ≥ 4; (2) N2 ≥ DW*2.

[0099] The sliding window is also equipped with a pointer to indicate the position where the sliding window can be written. The upper module inputs a DW byte width of data each time. After each data is input, the pointer value increases by DW, pointing to the latest position of the sliding window. When one or more data are input, making the pointer value greater than or equal to 4, the length information of the chunk is extracted from the B2~B4 position of the sliding window. At the same time, the sliding window is shifted left by 4 bytes, and the pointer value is subtracted by 4. At this time, the first data of the sliding window is the "data content" of the current chunk.

[0100] Since the upper module is constantly writing data to the sliding window of this module, after extracting the length information, each clock cycle determines whether the pointer value is greater than or equal to DW. If it is satisfied, the first DW bytes of the sliding window are output to the lower module for decompression. At the same time, the pointer value is subtracted from DW, and the extracted length value is also subtracted from DW. When the length value is reduced to less than or equal to DW, it means that it is the last data of the current chunk. When the remaining data in the sliding window is greater than or equal to the length value, the data corresponding to the length value is output, and the extraction and output of a chunk of data is completed.

[0101] Fig. 9 Schematic diagram of the structure of data content contained in a compressed block in one embodiment of the present invention. Fig. 9 The method steps shown are used to parse the compressed block data content (i.e., chunk_body) contained in the compressed block. Specifically, they include:

[0102] After the above processing, a total of N bytes of chunk data content is sent to this module, which is the chunk_body part in the figure below. The chunk_body part contains: (1) A four-byte CRC32 part. CRC32 is a cyclic redundancy check algorithm used to check the transmission data, mainly used to detect errors in data transmission or storage. (2) Length information encoded in Varint mode. This field occupies 1 to 3 bytes. Varint encoding is a method of serializing integers using one or more bytes. It encodes integers into variable-length bytes to achieve compression. (3) The rest is the compressed data part. The compressed data uses a tag method.

[0103] Here, a sliding window and pointer are also used to parse the uncompressedlength and compressed data parts from chunk_body. A sliding window is defined with a width of N3 bytes. N3 needs to satisfy the following conditions: (1) N3 ≥ 7; (2) N3 ≥ DW*2.

[0104] Fig.10The flowchart of parsing the length information of varint encoding in one embodiment of the present invention. When the pointer value in the sliding window is greater than or equal to 4, the data in the sliding window is shifted left by 4 bytes, and the CRC content of the first 4 bytes is discarded. After shifting left by four bytes, the fifth byte becomes the first data in the sliding window, and then the length information of the varint encoding format is parsed. The varint encoding format is defined as follows: (1) A varint data consists of one or more bytes, each byte has a total of 8 bits; (2) If the highest bit of each byte is 1, it means that the next byte still belongs to the current data. (3) If the highest bit of each byte is 0, it means that the current byte is the last byte of the current data. (4) The lower 7 bits of each byte of the current data are spliced, and the new data formed is the actual data represented by the varint. (5) In snappy compression, it is stipulated that the length information does not exceed 3 bytes, so the total number of bytes of varint does not exceed 3.

[0105] Fig.11 The following is a schematic diagram of the processing sequence for parsing the length information of the varint code in one embodiment of the present invention. First, the first byte B5 of the sliding window is read. If the highest bit of B5 is 0, it means that the next byte B6 is also varint data. The second byte B6 is read again. If the highest bit of B6 is 0, it means that the next byte B7 is also varint data. Since there are no more than 3 bytes at most, the highest bit is no longer determined when B7 is read. When determining the highest bit of B5 and B6, if the highest bit is 1, it means that the varint code ends, and the next byte is no longer determined.

[0106] Fig.12 The following is a flow chart of parsing varint codes by splicing in one embodiment of the present invention. When processing varint codes, a 21-bit length register is defined to store the parsed length information uncompressedlength (i.e., length information). After each varint byte is read, the lower 7 bits of the corresponding byte are spliced ​​to the register. The splicing method is as follows: (1) The initial value of the length register is 0; (2) After reading the first byte B5 of the sliding window, the lower 7 bits of B5 are placed in the lower 7 bits of the length register; (3) The highest bit of the first byte B5 is determined to be b7: ① If b7 is 0, it means that the next byte B6 is not varint data, so B6 is no longer read. The varint coding process is completed. Then the upper 14 bits of the length register are 0, and the lower 7 bits are composed of b7 to b0 of B5. ② If b7 is 1, it means that the next byte B6 is also varint data. B6 needs to be processed in the same way.

[0107] In the above varint encoding parsing process, the end position of the varint encoding is determined. When the highest bit of the first byte B5 is 0, it means that the current varint has only one byte and the varint encoding ends at the first byte, so the pointer of the sliding window is moved left by 1 byte. Similarly, when the varint ends at the second or third byte, the pointer of the sliding window is moved left by 2 or 3 bytes. This makes the compressed data (i.e., decompressed data, a decompressed data is obtained based on a compressed block, and the decompressed data is merged to obtain a path of original data) at the first byte.

[0108] At this point, the first byte of the sliding window starts as compressed data (i.e. compressed data, included in the block data content). The original data needs to be decompressed from the compressed data. Compressed data uses tags to compress data, and there are two forms of tags: (1) Literal tag: Indicates that the next data of a specified length has not appeared in the previous data, and this data can be directly output as decompressed data. Literal tag is divided into 5 forms, and the main difference lies in how many bytes are needed to represent the length information. (2) Copy tag: Indicates that the subsequent data of a specified length has appeared in the previously output data, and provides the offset position of the data. It needs to be extracted from the previous data and output as decompressed data. Copy tag is divided into 3 forms, and the main difference lies in the length information and offset position using multiple bytes. The specific format of the tag is as follows Fig.13 shown.

[0109] The way to distinguish between Literal tags and Copy tags is through the lower 2 bits of the first byte of the tag, that is, "type" in the figure below. When type = 00, it means the current tag is a literal tag. When type = 01, it means the current tag is a copy1 tag. When type = 10, it means the current tag is a copy2 tag. When type = 11, it means the current tag is a copy3 tag. The specific definitions of tags are as follows: (1) When type = 0, it is a literal tag, and the value of Bit [7:2] of the tag is ≤ 59, the value of Bit [7:2] is the length of the subsequent data. It means that the data with the corresponding length after the tag is directly output as decompressed data. (2) When type = 0, it is a literal tag, and the value of Bit [7:2] of the tag is = 60, the following byte indicates the length of the data. It means that the data with the corresponding length after the tag and length information is directly output as decompressed data. (3) Similarly, when the value of Bit[7:2] of the tag is 60, 61, or 62, the following 2, 3, or 4 bytes are used as length information, indicating that the data of the corresponding length after the tag and length information is directly output as decompressed data. (4) When type=01, it is a copy1 tag. The value of Bit[4:2] plus 4 is the length information of the data, and Bit[7:5] and the following byte form the 11-bit offset position offset. It indicates that length data appeared in the previously output data, and the position where it appeared is offset bytes forward of the current position. (5) When type=10, it is a copy2 tag. The value of Bit[7:2] plus 1 is the length information of the data, and the following 2 bytes form the offset position offset. It indicates that length data appeared in the previously output data, and the position where it appeared is offset bytes forward of the current position. (6) When type=11, it is a copy3 tag. The value of Bit[7:2] plus 1 is the length information of the data, and the following 4 bytes form the offset position offset. Indicates that length data has appeared in the previously output data, and the position where it appears is offset bytes forward from the current position.

[0110] Fig.14This is a schematic diagram of a write address register and a read address register in one embodiment of the present invention. From the above description, it can be seen that the copy tag means that a section of data to be output next has appeared in the previously output data. Therefore, a RAM memory is designed to cache the previously output data at the same time. After receiving the copy tag, the corresponding data is indexed from the RAM memory and output according to the offset and length information of the copy tag. Therefore, this section mainly defines a RAM memory with a bit width of DW and a total capacity of not less than 64KB. At the same time, a write address register and a read address register are defined. The write address register is mainly used to record the address of the written data, and the read address register calculates the address read from the RAM according to the offset and length information of the copy tag.

[0111] The units of write address and read address are both bytes, but the data transmission bit width and RAM bit width are DW. When DW is greater than 1 byte, the data written in RAM may not be an integer multiple of DW. Therefore, a temp register is designed to concatenate data into DW width and then write it into RAM. The bit width of the temp register is DW*2, which is consistent with the sliding window effect described in the previous section.

[0112] When writing data to RAM, first determine whether the value of the write address register is an integer multiple of DW. If it is, write the data directly to RAM. If it is not an integer multiple, first read the data in the RAM corresponding to the write address register and write it to the temp register, and then write the data to be written to the temp register for bit splicing. When the temp register is spliced ​​to the DW bit width, write the DW bit width data on the temp register to RAM, move the temp register to the right by DW bytes, and increment the RAM address.

[0113] Fig.15 The schematic diagram of the principle of reading a RAM register in an embodiment of the present invention is shown below. When reading the RAM, the read address is calculated by “read address = write address - offset - length”. After the read address is calculated, data of the corresponding length is read from the corresponding RAM and output.

[0114] At the end of the solution, the decompressed data is spliced ​​and output. Fig.16 and Fig.17As shown in the figure, the decompressed data comes from two parts: one is the decompressed data of the literal tag, which is directly extracted from the compressed data. The other is the copy tag data, which is extracted from the RAM. The two types of data need to be combined into one data output as the decompressed data. Therefore, this chapter designs a multi-choice switch and a sliding window to splice the two data and output them.

[0115] Fig.17 The schematic diagram of the principle of merging multiple data channels by using a sliding window in one embodiment of the present invention. The sliding window design is consistent with the above design, and is implemented by a register with a bit width of DW*2. At the same time, a pointer register is designed to record the position where data can be written into the sliding window. The data after multiple selection is written into the position specified by the pointer in the sliding window. When the data in the sliding window is sufficient for DW bytes, the data with the lower DW bytes is output. The output data is written into DDR for caching. At the same time, the pointer is backed off by DW bytes to indicate the latest writable position.

[0116] Another aspect of the present invention proposes a decompression implementation device based on a DPU acceleration card under a heterogeneous architecture. The DPU acceleration card establishes a connection with a CPU server to form a heterogeneous system. The DPU acceleration card includes a DDR storage unit and an acceleration core. The device includes: the DDR storage unit is used to receive and store a compressed data stream unloaded by the CPU server through an established connection, and reads sub-data streams of a preset byte length in the compressed data stream from the DDR storage unit in sequence to the acceleration core, and the acceleration core decompresses the sub-data streams; wherein the compressed data stream includes a compressed file, and the compressed file is composed of multiple compressed blocks, and the compressed block carries block type information; the acceleration core, It is used to decompress the sub-data stream, specifically including: using a sliding window method to compare and search for the starting position of the compressed file in the sub-data stream, the starting position of the compressed file is identified by block type information; for the compressed blocks that constitute the compressed file, parsing according to a preset decompression method to obtain the decompressed data contained in each compressed block in the compressed data stream; merging the decompressed data contained in each compressed block obtained by decompression into one path of original data; the DDR storage unit is also used to write back the original data obtained after decompression by the acceleration core, and transmit the original data back to the CPU server through the established connection, so as to realize decompression from compressed data stream to original data in a heterogeneous system.

[0117] In some specific embodiments of the present invention, a sliding window register is pre-set in the decompression implementation device based on the DPU acceleration card under the heterogeneous architecture to accelerate the decompression processing of the sub-data stream, and the sliding window register includes: a first sliding window register, which is used to compare and find the position of the first compressed block of the compressed file in the sub-data stream by using a sliding window method, so as to determine the starting position of each compressed file; wherein each compressed block also includes block length information and block data content; a second sliding window register, which is used to parse the block data content from the compressed block according to the block length information by using a sliding window method, and the block data content includes length information and compressed data, and read the compressed data that meets the length information from the block data content; use the label contained in the compressed data to decompress the decompressed data contained in a single compressed block from the compressed data; a third sliding window register, which is used to merge the decompressed data contained in each compressed block obtained by decompression based on different labels into one original data by using a sliding window method and a multiple-choice switch.

[0118] The method and device proposed in the present invention are applied to snappy decompression scenarios in the database and big data fields. The snappy decompression work can be offloaded from the original execution on the CPU to the execution on a heterogeneous system, which broadens the implementation scheme of the snappy decompression function and has the following improvements over the original technology:

[0119] (1) The architecture of the snappy decompression function is customized in the heterogeneous system. The snappy decompression function in the heterogeneous architecture is realized through a new design scheme, which greatly improves the snappy decompression rate.

[0120] (2) After the task is offloaded to the heterogeneous system, the CPU only needs to send some control instructions and no longer needs to perform heavy computing tasks. This frees up the CPU occupancy rate and provides space for the CPU to process other tasks.

[0121] (3) The heterogeneous architecture on which the acceleration core relies is used to achieve data interaction between the CPU and the DPU acceleration card.

[0122] The current invention can be applied to decompression in the database and big data fields, mainly by implementing decompression algorithms such as snappy on heterogeneous platforms; while the existing technical solution relies on the CPU to call the snappy decompression function to implement this process.

[0123] It should be understood by those skilled in the art that the exemplary components, systems and methods described in conjunction with the embodiments disclosed herein can be implemented in hardware, software or a combination of the two. Whether it is performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention. When implemented in hardware, it can be, for example, an electronic circuit, an application specific integrated circuit (ASIC), appropriate firmware, a plug-in, a function card, etc. When implemented in software, the elements of the present invention are programs or code segments used to perform the required tasks. The program or code segment can be stored in a machine-readable medium, or transmitted on a transmission medium or a communication link via a data signal carried in a carrier.

[0124] It should be clear that the present invention is not limited to the specific configuration and processing described above and shown in the figures. For the sake of simplicity, a detailed description of the known method is omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present invention is not limited to the specific steps described and shown, and those skilled in the art can make various changes, modifications and additions, or change the order between the steps after understanding the spirit of the present invention.

[0125] In the present invention, features described and / or illustrated for one embodiment may be used in the same or similar manner in one or more other embodiments, and / or combined with features of other embodiments or replace features of other embodiments.

[0126] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, the embodiments of the present invention may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A decompression implementation method based on a DPU accelerator card in a heterogeneous architecture, characterized in that: The DPU accelerator card is connected to the CPU server to form a heterogeneous system. The DPU accelerator card includes a DDR storage unit and an acceleration core. The method includes the following steps: The DPU accelerator card receives a compressed data stream unloaded by the CPU server through an established connection, and stores the compressed data stream in a DDR storage unit of the DPU accelerator card; wherein the compressed data stream includes a compressed file, the compressed file is composed of a plurality of compressed blocks, and the compressed block carries block type information; Reading sub-data streams of preset byte length in the compressed data stream from the DDR storage unit in sequence to the acceleration core, and decompressing the sub-data streams by the acceleration core; The step of accelerating the decompression of the sub-data stream includes: using a sliding window to compare and search for the starting position of the compressed file in the sub-data stream, the starting position of the compressed file is identified by block type information; for the compressed blocks constituting the compressed file, parsing according to a preset decompression method to obtain decompressed data contained in each compressed block in the compressed data stream; merging the decompressed data contained in each compressed block obtained by decompression into one path of original data; After decompression by the acceleration core, the decompressed original data is written back to the DDR storage unit, and the original data is transmitted back to the CPU server through the established connection.

2. The method according to claim 1, characterized in that Each compressed block also includes block length information and block data content. The step of using a sliding window to compare and search for the starting position of the compressed file in the sub-data stream includes: using a sliding window to compare and search for the position of the first compressed block of the compressed file in the sub-data stream, thereby determining the starting position of each compressed file.

3. The method according to claim 2, characterized in that The step of parsing the compressed data stream in accordance with a preset decompression method to obtain the decompressed data contained in each compressed block includes: parsing the block data content from the compressed block according to the block length information in a sliding window manner, the block data content including the length information and the compressed data, and reading the compressed data that conforms to the length information from the block data content; and decompressing the decompressed data contained in a single compressed block from the compressed data using a tag contained in the compressed data.

4. The method according to claim 3, characterized in that: The step of merging the decompressed data contained in each compressed block obtained by decompression into one path of original data includes: using a multiple-choice switch to merge the decompressed data contained in each compressed block obtained by decompression based on different tags into one path of original data.

5. The method according to claim 4, characterized in that The block data content also includes cyclic redundancy check bits for detecting or checking decoded data errors; The length information contained in the block data content is encoded using the varint encoding rule.

6. The method according to claim 4, characterized in that The types of the tags include literal tags and copy tags; The step of decompressing the decompressed data contained in a single compressed block from the compressed data using the tag contained in the compressed data includes: when the tag type is a literal tag, directly using the data of a specified length in the compressed data as the decompressed data; when the tag type is a copy tag, copying the data of a specified length from the previous data as the decompressed data according to the offset position contained in the compressed data.

7. The method according to claim 4, characterized in that The copy tag is further divided into multiple copy forms according to length information and offset position, and the copy form keyword is used to identify the compressed data; The prior data is cached through a pre-designed RAM memory, a read address register, and a write address register on the DPU accelerator card for reading and copying.

8. The method according to claim 1, characterized in that The preset decompression mode includes any one of snappy decompression, Gzip decompression, LZ4 decompression and Brotli decompression; The DPU accelerator card is connected to the CPU server through a PCIe channel or a network interface.

9. A decompression implementation device based on a DPU accelerator card under a heterogeneous architecture, characterized in that: The DPU accelerator card is connected to the CPU server to form a heterogeneous system. The DPU accelerator card includes a DDR storage unit and an acceleration core. The device includes: The DDR storage unit is used to receive and store the compressed data stream unloaded by the CPU server through the established connection, and sequentially read the sub-data streams of the preset byte length in the compressed data stream from the DDR storage unit to the acceleration core, and the acceleration core decompresses the sub-data streams; wherein the compressed data stream includes a compressed file, the compressed file is composed of a plurality of compressed blocks, and the compressed blocks carry block type information; The acceleration core is used to decompress the sub-data stream, specifically including: using a sliding window method to compare and search for the starting position of the compressed file in the sub-data stream, the starting position of the compressed file is identified by block type information; for the compressed blocks constituting the compressed file, parsing according to a preset decompression method to obtain decompressed data contained in each compressed block in the compressed data stream; merging the decompressed data contained in each compressed block obtained by decompression into one path of original data; The DDR storage unit is also used to write back the original data obtained after decompression by the acceleration core, and transmit the original data back to the CPU server through the established connection.

10. The device according to claim 9, characterized in that The decompression implementation device based on the DPU acceleration card under the heterogeneous architecture is pre-set with a sliding window register for accelerating the core to decompress the sub-data stream, and the sliding window register includes: A first sliding window register, used for comparing and searching the position of the first compressed block of the compressed file in the sub-data stream by means of a sliding window, so as to determine the starting position of each compressed file; wherein each compressed block also includes block length information and block data content; The second sliding window register is used to parse the block data content from the compressed block according to the block length information by using a sliding window method, wherein the block data content includes the length information and the compressed data, and read the compressed data that meets the length information from the block data content; and decompress the decompressed data included in the single compressed block from the compressed data by using the tag included in the compressed data; The third sliding window register is used to merge the decompressed data contained in each compressed block obtained by decompression based on different tags into one path of original data by using a sliding window method and a multiple-choice switch.

Images