|
| 1 | +# ISA-L Function Overview |
| 2 | + |
| 3 | +ISA-L is logically broken into mostly independent units based on the source |
| 4 | +directories of the same name. |
| 5 | +- erasure_codes |
| 6 | +- crc |
| 7 | +- raid |
| 8 | +- mem |
| 9 | +- igzip |
| 10 | + |
| 11 | +The library can also be built with subsets of available units. For example |
| 12 | +`$ make -f Makefile.unx units=crc` will only build a library with crc |
| 13 | +functions. |
| 14 | + |
| 15 | +## ISA-L Functions |
| 16 | + |
| 17 | +### Erasure Code Functions |
| 18 | + |
| 19 | +Functions pertaining to erasure codes implement a general Reed-Solomon type |
| 20 | +encoding for blocks of data to protect against erasure of whole blocks. |
| 21 | +Individual operations can be described in terms of arithmetic in the Galois |
| 22 | +finite field GF(2^8) with the particular field-defining primitive or reducing |
| 23 | +polynomial \f$ x^8 + x^4 + x^3 + x^2 + 1 \f$ (0x1d). |
| 24 | + |
| 25 | +For example, the function ec_encode_data() will generate a set of parity blocks |
| 26 | +\f$P_i\f$ from the set of k source blocks \f$D_i\f$ and arbitrary encoding |
| 27 | +coefficients \f$a_{i,j}\f$ where each byte in P is calculated from sources as: |
| 28 | + |
| 29 | +\f[ P_i = \sum_{j=1}^k a_{i,j} \cdot D_j \f] |
| 30 | + |
| 31 | +where addition and multiplication \f$\cdot\f$ is defined in GF(2^8). Since any |
| 32 | +arbitrary set of coefficients \f$a_{i,j}\f$ can be supplied, the same |
| 33 | +fundamental function can be used for encoding blocks or decoding from blocks in |
| 34 | +erasure. |
| 35 | + |
| 36 | +#### EC Usage |
| 37 | + |
| 38 | +Various examples are available in examples/ec and unit tests in `erasure_code` |
| 39 | +to show an encode and decode (re-hydrate) cycle or partial update operation. As |
| 40 | +seen in [ec example] the process starts with picking an |
| 41 | +encode matrix, parameters k (source blocks) and m (total parity + source |
| 42 | +blocks), and expanding the necessary coefficients. |
| 43 | + |
| 44 | +~~~c |
| 45 | + // Initialize g_tbls from encode matrix |
| 46 | + ec_init_tables(k, p, &encode_matrix[k * k], g_tbls); |
| 47 | +~~~ |
| 48 | +
|
| 49 | +In the example, a symmetric encode matrix is used where only the coefficients |
| 50 | +describing the parity blocks are used for encode and the upper matrix is |
| 51 | +initialized as an identity to simplify generation of the corresponding decode |
| 52 | +matrix. Next the parity for all (m - k) blocks are calculated at once. |
| 53 | +
|
| 54 | +~~~c |
| 55 | + // Generate EC parity blocks from sources |
| 56 | + ec_encode_data(len, k, p, g_tbls, frag_ptrs, &frag_ptrs[k]); |
| 57 | +~~~ |
| 58 | + |
| 59 | +### RAID Functions |
| 60 | + |
| 61 | +Functions in the RAID section calculate and operate on XOR and P+Q parity found |
| 62 | +in common RAID implementations. The mathematics of RAID are based on Galois |
| 63 | +finite-field arithmetic to find one or two parity bytes for each byte in N |
| 64 | +sources such that single or dual disk failures (one or two erasures) can be |
| 65 | +corrected. For RAID5, a block of parity is calculated by the xor across the N |
| 66 | +source arrays. Each parity byte is calculated from N sources by: |
| 67 | + |
| 68 | +\f[ P = D_0 + D_1 + ... + D_{N-1} \f] |
| 69 | + |
| 70 | +where \f$D_n\f$ are elements across each source array [0-(N-1)] and + is the |
| 71 | +bit-wise exclusive or (xor) operation. Elements in GF(2^8) are implemented as |
| 72 | +bytes. |
| 73 | + |
| 74 | +For RAID6, two parity bytes P and Q are calculated from the source array. P is |
| 75 | +calculated as in RAID5 and Q is calculated using the generator g as: |
| 76 | + |
| 77 | +\f[ Q = g^0 D_0 + g^1 D_1 + g^2 D_2 + ... + g^{N-1} D_{N-1} \f] |
| 78 | + |
| 79 | +where g is chosen as {2}, the second field element. Multiplication and the |
| 80 | +field are defined using the primitive polynomial \f$ x^8 + x^4 + x^3 + x^2 + 1 \f$ |
| 81 | +(0x1d). |
| 82 | + |
| 83 | +#### RAID Usage |
| 84 | + |
| 85 | +RAID function usage is similar to erasure code except no coefficient expansion |
| 86 | +step is necessary. As seen in [raid example] the xor_gen() and xor_check() |
| 87 | +functions are used to generate and check parity. |
| 88 | + |
| 89 | +### CRC Functions |
| 90 | + |
| 91 | +Functions in the CRC section include fast implementations of cyclic redundancy |
| 92 | +check using specialized instructions such as PCLMULQDQ, carry-less |
| 93 | +multiplication. Generally, a CRC is the remainder in binary division of a |
| 94 | +message and a CRC polynomial in GF(2). |
| 95 | + |
| 96 | +\f[ CRC(M(x)) = x^{deg(P(x))} \cdot M(x) \, mod \, P(x) \f] |
| 97 | + |
| 98 | +CRC is used in many storage applications to ensure integrity of data by |
| 99 | +appending the CRC to a message. Various standards choose the polynomial P and |
| 100 | +may vary by initial seeding value, bit reversal and inverting the result and |
| 101 | +seed. |
| 102 | + |
| 103 | +#### CRC Usage |
| 104 | + |
| 105 | +CRC functions have a simple interface such as in [crc example]. |
| 106 | + |
| 107 | +~~~c |
| 108 | + crc64_checksum = crc64_ecma_refl(crc64_checksum, inbuf, avail_in); |
| 109 | +~~~ |
| 110 | + |
| 111 | +Updates with new buffers are possible with subsequent calls. No extra finalize |
| 112 | +step is necessary. |
| 113 | + |
| 114 | +### Compress/Inflate Functions |
| 115 | + |
| 116 | +Functions in the igzip unit perform fast, loss-less data compression and |
| 117 | +decompression within the [deflate](https://www.ietf.org/rfc/rfc1951.txt), |
| 118 | +[zlib](https://www.ietf.org/rfc/rfc1950.txt), and |
| 119 | +[gzip](https://www.ietf.org/rfc/rfc1952.txt) binary standards. Functions for |
| 120 | +stream based (data pieces at a time) and stateless (data all at once) are |
| 121 | +available as well as multiple parameters to change the speed vs. compression |
| 122 | +ratio or other features. In addition, there are functions to fine tune |
| 123 | +compression by pre-computing static Huffman tables and setting for subsequent |
| 124 | +compression runs, parsing compression headers and other specific tasks to give |
| 125 | +more control. |
| 126 | + |
| 127 | +#### Compress/Inflate Usage |
| 128 | + |
| 129 | +The interface for compression and decompression functions is similar to zlib, |
| 130 | +zstd and others where a context structure keeps parameters and internal state to |
| 131 | +render from an input buffer to an output buffer. I/O buffer pointers and size |
| 132 | +are often the only required settings. ISA-L, unlike zlib and others, does not |
| 133 | +allocate new memory and must be done by the user explicitly when required (level |
| 134 | +1 and above). This gives the user more flexibility to when dynamic memory is |
| 135 | +allocated and reused. The minimum code for starting a compression is just |
| 136 | +allocating a stream structure and initializing it. This can be done just once |
| 137 | +for multiple compression runs. |
| 138 | + |
| 139 | +~~~c |
| 140 | + struct isal_zstream stream; |
| 141 | + isal_deflate_init(&stream); |
| 142 | +~~~ |
| 143 | +
|
| 144 | +Using level 1 compression and above requires an additional, initial allocation |
| 145 | +for an internal intermediate buffer. Suggested sizes are defined in external |
| 146 | +headers. |
| 147 | +
|
| 148 | +~~~c |
| 149 | + stream.level = 1; |
| 150 | + stream.level_buf = malloc(ISAL_DEF_LVL1_DEFAULT); |
| 151 | + stream.level_buf_size = ISAL_DEF_LVL1_DEFAULT; |
| 152 | +~~~ |
| 153 | + |
| 154 | +After init, subsequent, multiple compression runs can be performed by supplying |
| 155 | +(or re-using) I/O buffers. |
| 156 | + |
| 157 | +~~~c |
| 158 | + stream.next_in = inbuf; |
| 159 | + stream->next_out = outbuf; |
| 160 | + stream->avail_in = inbuf_size; |
| 161 | + stream->avail_out = outbuf_size; |
| 162 | + |
| 163 | + isal_deflate(stream); |
| 164 | +~~~ |
| 165 | +
|
| 166 | +See [igzip example] for a simple example program or review the perf or check |
| 167 | +tests for more. |
| 168 | +
|
| 169 | +**igzip**: ISA-L also provides a user program *igzip* to compress and decompress |
| 170 | +files. Optionally igzip can be compiled with multi-threaded compression. See |
| 171 | +`man igzip` for details. |
| 172 | +
|
| 173 | +## General Library Features |
| 174 | +
|
| 175 | +### Multi-Binary Dispatchers |
| 176 | +
|
| 177 | +Multibinary support is available for all units in ISA-L. With multibinary |
| 178 | +support functions, an appropriate version is selected at first run and can be |
| 179 | +called instead of architecture-specific versions. This allows users to deploy a |
| 180 | +single binary with multiple function versions and choose at run time based on |
| 181 | +platform features. All functions also have base functions, written in portable |
| 182 | +C, which the multibinary function will call if none of the required instruction |
| 183 | +sets are enabled. |
| 184 | +
|
| 185 | +### Included Tests and Utilities |
| 186 | +
|
| 187 | +ISA-L source [repo] includes unit tests, performance tests and other utilities. |
| 188 | +
|
| 189 | +Examples: |
| 190 | +- [ec example] |
| 191 | +- [raid example] |
| 192 | +- [crc example] |
| 193 | +- [igzip example] |
| 194 | +
|
| 195 | +--- |
| 196 | +
|
| 197 | +[repo]: https://github.com/intel/isa-l |
| 198 | +[ec example]: https://github.com/intel/isa-l/blob/master/examples/ec/ec_simple_example.c |
| 199 | +[raid example]: https://github.com/intel/isa-l/blob/master/raid/xor_example.c |
| 200 | +[crc example]: https://github.com/intel/isa-l/blob/master/crc/crc64_example.c |
| 201 | +[igzip example]: https://github.com/intel/isa-l/blob/master/igzip/igzip_example.c |
0 commit comments