remove experimental tags from all symbol definitions
[dpdk.git] / lib / librte_cryptodev / rte_crypto_sym.h
1 /* SPDX-License-Identifier: BSD-3-Clause
2  * Copyright(c) 2016-2019 Intel Corporation
3  */
4
5 #ifndef _RTE_CRYPTO_SYM_H_
6 #define _RTE_CRYPTO_SYM_H_
7
8 /**
9  * @file rte_crypto_sym.h
10  *
11  * RTE Definitions for Symmetric Cryptography
12  *
13  * Defines symmetric cipher and authentication algorithms and modes, as well
14  * as supported symmetric crypto operation combinations.
15  */
16
17 #ifdef __cplusplus
18 extern "C" {
19 #endif
20
21 #include <string.h>
22
23 #include <rte_mbuf.h>
24 #include <rte_memory.h>
25 #include <rte_mempool.h>
26 #include <rte_common.h>
27
28
29 /** Symmetric Cipher Algorithms */
30 enum rte_crypto_cipher_algorithm {
31         RTE_CRYPTO_CIPHER_NULL = 1,
32         /**< NULL cipher algorithm. No mode applies to the NULL algorithm. */
33
34         RTE_CRYPTO_CIPHER_3DES_CBC,
35         /**< Triple DES algorithm in CBC mode */
36         RTE_CRYPTO_CIPHER_3DES_CTR,
37         /**< Triple DES algorithm in CTR mode */
38         RTE_CRYPTO_CIPHER_3DES_ECB,
39         /**< Triple DES algorithm in ECB mode */
40
41         RTE_CRYPTO_CIPHER_AES_CBC,
42         /**< AES algorithm in CBC mode */
43         RTE_CRYPTO_CIPHER_AES_CTR,
44         /**< AES algorithm in Counter mode */
45         RTE_CRYPTO_CIPHER_AES_ECB,
46         /**< AES algorithm in ECB mode */
47         RTE_CRYPTO_CIPHER_AES_F8,
48         /**< AES algorithm in F8 mode */
49         RTE_CRYPTO_CIPHER_AES_XTS,
50         /**< AES algorithm in XTS mode */
51
52         RTE_CRYPTO_CIPHER_ARC4,
53         /**< (A)RC4 cipher algorithm */
54
55         RTE_CRYPTO_CIPHER_KASUMI_F8,
56         /**< KASUMI algorithm in F8 mode */
57
58         RTE_CRYPTO_CIPHER_SNOW3G_UEA2,
59         /**< SNOW 3G algorithm in UEA2 mode */
60
61         RTE_CRYPTO_CIPHER_ZUC_EEA3,
62         /**< ZUC algorithm in EEA3 mode */
63
64         RTE_CRYPTO_CIPHER_DES_CBC,
65         /**< DES algorithm in CBC mode */
66
67         RTE_CRYPTO_CIPHER_AES_DOCSISBPI,
68         /**< AES algorithm using modes required by
69          * DOCSIS Baseline Privacy Plus Spec.
70          * Chained mbufs are not supported in this mode, i.e. rte_mbuf.next
71          * for m_src and m_dst in the rte_crypto_sym_op must be NULL.
72          */
73
74         RTE_CRYPTO_CIPHER_DES_DOCSISBPI,
75         /**< DES algorithm using modes required by
76          * DOCSIS Baseline Privacy Plus Spec.
77          * Chained mbufs are not supported in this mode, i.e. rte_mbuf.next
78          * for m_src and m_dst in the rte_crypto_sym_op must be NULL.
79          */
80
81         RTE_CRYPTO_CIPHER_LIST_END
82
83 };
84
85 /** Cipher algorithm name strings */
86 extern const char *
87 rte_crypto_cipher_algorithm_strings[];
88
89 /** Symmetric Cipher Direction */
90 enum rte_crypto_cipher_operation {
91         RTE_CRYPTO_CIPHER_OP_ENCRYPT,
92         /**< Encrypt cipher operation */
93         RTE_CRYPTO_CIPHER_OP_DECRYPT
94         /**< Decrypt cipher operation */
95 };
96
97 /** Cipher operation name strings */
98 extern const char *
99 rte_crypto_cipher_operation_strings[];
100
101 /**
102  * Symmetric Cipher Setup Data.
103  *
104  * This structure contains data relating to Cipher (Encryption and Decryption)
105  *  use to create a session.
106  */
107 struct rte_crypto_cipher_xform {
108         enum rte_crypto_cipher_operation op;
109         /**< This parameter determines if the cipher operation is an encrypt or
110          * a decrypt operation. For the RC4 algorithm and the F8/CTR modes,
111          * only encrypt operations are valid.
112          */
113         enum rte_crypto_cipher_algorithm algo;
114         /**< Cipher algorithm */
115
116         struct {
117                 uint8_t *data;  /**< pointer to key data */
118                 uint16_t length;/**< key length in bytes */
119         } key;
120         /**< Cipher key
121          *
122          * For the RTE_CRYPTO_CIPHER_AES_F8 mode of operation, key.data will
123          * point to a concatenation of the AES encryption key followed by a
124          * keymask. As per RFC3711, the keymask should be padded with trailing
125          * bytes to match the length of the encryption key used.
126          *
127          * Cipher key length is in bytes. For AES it can be 128 bits (16 bytes),
128          * 192 bits (24 bytes) or 256 bits (32 bytes).
129          *
130          * For the RTE_CRYPTO_CIPHER_AES_F8 mode of operation, key.length
131          * should be set to the combined length of the encryption key and the
132          * keymask. Since the keymask and the encryption key are the same size,
133          * key.length should be set to 2 x the AES encryption key length.
134          *
135          * For the AES-XTS mode of operation:
136          *  - Two keys must be provided and key.length refers to total length of
137          *    the two keys.
138          *  - key.data must point to the two keys concatenated together
139          *    (key1 || key2).
140          *  - Each key can be either 128 bits (16 bytes) or 256 bits (32 bytes).
141          *  - Both keys must have the same size.
142          **/
143         struct {
144                 uint16_t offset;
145                 /**< Starting point for Initialisation Vector or Counter,
146                  * specified as number of bytes from start of crypto
147                  * operation (rte_crypto_op).
148                  *
149                  * - For block ciphers in CBC or F8 mode, or for KASUMI
150                  * in F8 mode, or for SNOW 3G in UEA2 mode, this is the
151                  * Initialisation Vector (IV) value.
152                  *
153                  * - For block ciphers in CTR mode, this is the counter.
154                  *
155                  * - For GCM mode, this is either the IV (if the length
156                  * is 96 bits) or J0 (for other sizes), where J0 is as
157                  * defined by NIST SP800-38D. Regardless of the IV
158                  * length, a full 16 bytes needs to be allocated.
159                  *
160                  * - For CCM mode, the first byte is reserved, and the
161                  * nonce should be written starting at &iv[1] (to allow
162                  * space for the implementation to write in the flags
163                  * in the first byte). Note that a full 16 bytes should
164                  * be allocated, even though the length field will
165                  * have a value less than this. Note that the PMDs may
166                  * modify the memory reserved (the first byte and the
167                  * final padding)
168                  *
169                  * - For AES-XTS, this is the 128bit tweak, i, from
170                  * IEEE Std 1619-2007.
171                  *
172                  * For optimum performance, the data pointed to SHOULD
173                  * be 8-byte aligned.
174                  */
175                 uint16_t length;
176                 /**< Length of valid IV data.
177                  *
178                  * - For block ciphers in CBC or F8 mode, or for KASUMI
179                  * in F8 mode, or for SNOW 3G in UEA2 mode, this is the
180                  * length of the IV (which must be the same as the
181                  * block length of the cipher).
182                  *
183                  * - For block ciphers in CTR mode, this is the length
184                  * of the counter (which must be the same as the block
185                  * length of the cipher).
186                  *
187                  * - For GCM mode, this is either 12 (for 96-bit IVs)
188                  * or 16, in which case data points to J0.
189                  *
190                  * - For CCM mode, this is the length of the nonce,
191                  * which can be in the range 7 to 13 inclusive.
192                  */
193         } iv;   /**< Initialisation vector parameters */
194 };
195
196 /** Symmetric Authentication / Hash Algorithms */
197 enum rte_crypto_auth_algorithm {
198         RTE_CRYPTO_AUTH_NULL = 1,
199         /**< NULL hash algorithm. */
200
201         RTE_CRYPTO_AUTH_AES_CBC_MAC,
202         /**< AES-CBC-MAC algorithm. Only 128-bit keys are supported. */
203         RTE_CRYPTO_AUTH_AES_CMAC,
204         /**< AES CMAC algorithm. */
205         RTE_CRYPTO_AUTH_AES_GMAC,
206         /**< AES GMAC algorithm. */
207         RTE_CRYPTO_AUTH_AES_XCBC_MAC,
208         /**< AES XCBC algorithm. */
209
210         RTE_CRYPTO_AUTH_KASUMI_F9,
211         /**< KASUMI algorithm in F9 mode. */
212
213         RTE_CRYPTO_AUTH_MD5,
214         /**< MD5 algorithm */
215         RTE_CRYPTO_AUTH_MD5_HMAC,
216         /**< HMAC using MD5 algorithm */
217
218         RTE_CRYPTO_AUTH_SHA1,
219         /**< 128 bit SHA algorithm. */
220         RTE_CRYPTO_AUTH_SHA1_HMAC,
221         /**< HMAC using 128 bit SHA algorithm. */
222         RTE_CRYPTO_AUTH_SHA224,
223         /**< 224 bit SHA algorithm. */
224         RTE_CRYPTO_AUTH_SHA224_HMAC,
225         /**< HMAC using 224 bit SHA algorithm. */
226         RTE_CRYPTO_AUTH_SHA256,
227         /**< 256 bit SHA algorithm. */
228         RTE_CRYPTO_AUTH_SHA256_HMAC,
229         /**< HMAC using 256 bit SHA algorithm. */
230         RTE_CRYPTO_AUTH_SHA384,
231         /**< 384 bit SHA algorithm. */
232         RTE_CRYPTO_AUTH_SHA384_HMAC,
233         /**< HMAC using 384 bit SHA algorithm. */
234         RTE_CRYPTO_AUTH_SHA512,
235         /**< 512 bit SHA algorithm. */
236         RTE_CRYPTO_AUTH_SHA512_HMAC,
237         /**< HMAC using 512 bit SHA algorithm. */
238
239         RTE_CRYPTO_AUTH_SNOW3G_UIA2,
240         /**< SNOW 3G algorithm in UIA2 mode. */
241
242         RTE_CRYPTO_AUTH_ZUC_EIA3,
243         /**< ZUC algorithm in EIA3 mode */
244
245         RTE_CRYPTO_AUTH_SHA3_224,
246         /**< 224 bit SHA3 algorithm. */
247         RTE_CRYPTO_AUTH_SHA3_224_HMAC,
248         /**< HMAC using 224 bit SHA3 algorithm. */
249         RTE_CRYPTO_AUTH_SHA3_256,
250         /**< 256 bit SHA3 algorithm. */
251         RTE_CRYPTO_AUTH_SHA3_256_HMAC,
252         /**< HMAC using 256 bit SHA3 algorithm. */
253         RTE_CRYPTO_AUTH_SHA3_384,
254         /**< 384 bit SHA3 algorithm. */
255         RTE_CRYPTO_AUTH_SHA3_384_HMAC,
256         /**< HMAC using 384 bit SHA3 algorithm. */
257         RTE_CRYPTO_AUTH_SHA3_512,
258         /**< 512 bit SHA3 algorithm. */
259         RTE_CRYPTO_AUTH_SHA3_512_HMAC,
260         /**< HMAC using 512 bit SHA3 algorithm. */
261
262         RTE_CRYPTO_AUTH_LIST_END
263 };
264
265 /** Authentication algorithm name strings */
266 extern const char *
267 rte_crypto_auth_algorithm_strings[];
268
269 /** Symmetric Authentication / Hash Operations */
270 enum rte_crypto_auth_operation {
271         RTE_CRYPTO_AUTH_OP_VERIFY,      /**< Verify authentication digest */
272         RTE_CRYPTO_AUTH_OP_GENERATE     /**< Generate authentication digest */
273 };
274
275 /** Authentication operation name strings */
276 extern const char *
277 rte_crypto_auth_operation_strings[];
278
279 /**
280  * Authentication / Hash transform data.
281  *
282  * This structure contains data relating to an authentication/hash crypto
283  * transforms. The fields op, algo and digest_length are common to all
284  * authentication transforms and MUST be set.
285  */
286 struct rte_crypto_auth_xform {
287         enum rte_crypto_auth_operation op;
288         /**< Authentication operation type */
289         enum rte_crypto_auth_algorithm algo;
290         /**< Authentication algorithm selection */
291
292         struct {
293                 uint8_t *data;  /**< pointer to key data */
294                 uint16_t length;/**< key length in bytes */
295         } key;
296         /**< Authentication key data.
297          * The authentication key length MUST be less than or equal to the
298          * block size of the algorithm. It is the callers responsibility to
299          * ensure that the key length is compliant with the standard being used
300          * (for example RFC 2104, FIPS 198a).
301          */
302
303         struct {
304                 uint16_t offset;
305                 /**< Starting point for Initialisation Vector or Counter,
306                  * specified as number of bytes from start of crypto
307                  * operation (rte_crypto_op).
308                  *
309                  * - For SNOW 3G in UIA2 mode, for ZUC in EIA3 mode and
310                  *   for AES-GMAC, this is the authentication
311                  *   Initialisation Vector (IV) value.
312                  *
313                  * - For KASUMI in F9 mode and other authentication
314                  *   algorithms, this field is not used.
315                  *
316                  * For optimum performance, the data pointed to SHOULD
317                  * be 8-byte aligned.
318                  */
319                 uint16_t length;
320                 /**< Length of valid IV data.
321                  *
322                  * - For SNOW3G in UIA2 mode, for ZUC in EIA3 mode and
323                  *   for AES-GMAC, this is the length of the IV.
324                  *
325                  * - For KASUMI in F9 mode and other authentication
326                  *   algorithms, this field is not used.
327                  *
328                  */
329         } iv;   /**< Initialisation vector parameters */
330
331         uint16_t digest_length;
332         /**< Length of the digest to be returned. If the verify option is set,
333          * this specifies the length of the digest to be compared for the
334          * session.
335          *
336          * It is the caller's responsibility to ensure that the
337          * digest length is compliant with the hash algorithm being used.
338          * If the value is less than the maximum length allowed by the hash,
339          * the result shall be truncated.
340          */
341 };
342
343
344 /** Symmetric AEAD Algorithms */
345 enum rte_crypto_aead_algorithm {
346         RTE_CRYPTO_AEAD_AES_CCM = 1,
347         /**< AES algorithm in CCM mode. */
348         RTE_CRYPTO_AEAD_AES_GCM,
349         /**< AES algorithm in GCM mode. */
350         RTE_CRYPTO_AEAD_LIST_END
351 };
352
353 /** AEAD algorithm name strings */
354 extern const char *
355 rte_crypto_aead_algorithm_strings[];
356
357 /** Symmetric AEAD Operations */
358 enum rte_crypto_aead_operation {
359         RTE_CRYPTO_AEAD_OP_ENCRYPT,
360         /**< Encrypt and generate digest */
361         RTE_CRYPTO_AEAD_OP_DECRYPT
362         /**< Verify digest and decrypt */
363 };
364
365 /** Authentication operation name strings */
366 extern const char *
367 rte_crypto_aead_operation_strings[];
368
369 struct rte_crypto_aead_xform {
370         enum rte_crypto_aead_operation op;
371         /**< AEAD operation type */
372         enum rte_crypto_aead_algorithm algo;
373         /**< AEAD algorithm selection */
374
375         struct {
376                 uint8_t *data;  /**< pointer to key data */
377                 uint16_t length;/**< key length in bytes */
378         } key;
379
380         struct {
381                 uint16_t offset;
382                 /**< Starting point for Initialisation Vector or Counter,
383                  * specified as number of bytes from start of crypto
384                  * operation (rte_crypto_op).
385                  *
386                  * - For GCM mode, this is either the IV (if the length
387                  * is 96 bits) or J0 (for other sizes), where J0 is as
388                  * defined by NIST SP800-38D. Regardless of the IV
389                  * length, a full 16 bytes needs to be allocated.
390                  *
391                  * - For CCM mode, the first byte is reserved, and the
392                  * nonce should be written starting at &iv[1] (to allow
393                  * space for the implementation to write in the flags
394                  * in the first byte). Note that a full 16 bytes should
395                  * be allocated, even though the length field will
396                  * have a value less than this.
397                  *
398                  * For optimum performance, the data pointed to SHOULD
399                  * be 8-byte aligned.
400                  */
401                 uint16_t length;
402                 /**< Length of valid IV data.
403                  *
404                  * - For GCM mode, this is either 12 (for 96-bit IVs)
405                  * or 16, in which case data points to J0.
406                  *
407                  * - For CCM mode, this is the length of the nonce,
408                  * which can be in the range 7 to 13 inclusive.
409                  */
410         } iv;   /**< Initialisation vector parameters */
411
412         uint16_t digest_length;
413
414         uint16_t aad_length;
415         /**< The length of the additional authenticated data (AAD) in bytes.
416          * For CCM mode, this is the length of the actual AAD, even though
417          * it is required to reserve 18 bytes before the AAD and padding
418          * at the end of it, so a multiple of 16 bytes is allocated.
419          */
420 };
421
422 /** Crypto transformation types */
423 enum rte_crypto_sym_xform_type {
424         RTE_CRYPTO_SYM_XFORM_NOT_SPECIFIED = 0, /**< No xform specified */
425         RTE_CRYPTO_SYM_XFORM_AUTH,              /**< Authentication xform */
426         RTE_CRYPTO_SYM_XFORM_CIPHER,            /**< Cipher xform  */
427         RTE_CRYPTO_SYM_XFORM_AEAD               /**< AEAD xform  */
428 };
429
430 /**
431  * Symmetric crypto transform structure.
432  *
433  * This is used to specify the crypto transforms required, multiple transforms
434  * can be chained together to specify a chain transforms such as authentication
435  * then cipher, or cipher then authentication. Each transform structure can
436  * hold a single transform, the type field is used to specify which transform
437  * is contained within the union
438  */
439 struct rte_crypto_sym_xform {
440         struct rte_crypto_sym_xform *next;
441         /**< next xform in chain */
442         enum rte_crypto_sym_xform_type type
443         ; /**< xform type */
444         RTE_STD_C11
445         union {
446                 struct rte_crypto_auth_xform auth;
447                 /**< Authentication / hash xform */
448                 struct rte_crypto_cipher_xform cipher;
449                 /**< Cipher xform */
450                 struct rte_crypto_aead_xform aead;
451                 /**< AEAD xform */
452         };
453 };
454
455 struct rte_cryptodev_sym_session;
456
457 /**
458  * Symmetric Cryptographic Operation.
459  *
460  * This structure contains data relating to performing symmetric cryptographic
461  * processing on a referenced mbuf data buffer.
462  *
463  * When a symmetric crypto operation is enqueued with the device for processing
464  * it must have a valid *rte_mbuf* structure attached, via m_src parameter,
465  * which contains the source data which the crypto operation is to be performed
466  * on.
467  * While the mbuf is in use by a crypto operation no part of the mbuf should be
468  * changed by the application as the device may read or write to any part of the
469  * mbuf. In the case of hardware crypto devices some or all of the mbuf
470  * may be DMAed in and out of the device, so writing over the original data,
471  * though only the part specified by the rte_crypto_sym_op for transformation
472  * will be changed.
473  * Out-of-place (OOP) operation, where the source mbuf is different to the
474  * destination mbuf, is a special case. Data will be copied from m_src to m_dst.
475  * The part copied includes all the parts of the source mbuf that will be
476  * operated on, based on the cipher.data.offset+cipher.data.length and
477  * auth.data.offset+auth.data.length values in the rte_crypto_sym_op. The part
478  * indicated by the cipher parameters will be transformed, any extra data around
479  * this indicated by the auth parameters will be copied unchanged from source to
480  * destination mbuf.
481  * Also in OOP operation the cipher.data.offset and auth.data.offset apply to
482  * both source and destination mbufs. As these offsets are relative to the
483  * data_off parameter in each mbuf this can result in the data written to the
484  * destination buffer being at a different alignment, relative to buffer start,
485  * to the data in the source buffer.
486  */
487 struct rte_crypto_sym_op {
488         struct rte_mbuf *m_src; /**< source mbuf */
489         struct rte_mbuf *m_dst; /**< destination mbuf */
490
491         RTE_STD_C11
492         union {
493                 struct rte_cryptodev_sym_session *session;
494                 /**< Handle for the initialised session context */
495                 struct rte_crypto_sym_xform *xform;
496                 /**< Session-less API crypto operation parameters */
497                 struct rte_security_session *sec_session;
498                 /**< Handle for the initialised security session context */
499         };
500
501         RTE_STD_C11
502         union {
503                 struct {
504                         struct {
505                                 uint32_t offset;
506                                  /**< Starting point for AEAD processing, specified as
507                                   * number of bytes from start of packet in source
508                                   * buffer.
509                                   */
510                                 uint32_t length;
511                                  /**< The message length, in bytes, of the source buffer
512                                   * on which the cryptographic operation will be
513                                   * computed. This must be a multiple of the block size
514                                   */
515                         } data; /**< Data offsets and length for AEAD */
516                         struct {
517                                 uint8_t *data;
518                                 /**< This points to the location where the digest result
519                                  * should be inserted (in the case of digest generation)
520                                  * or where the purported digest exists (in the case of
521                                  * digest verification).
522                                  *
523                                  * At session creation time, the client specified the
524                                  * digest result length with the digest_length member
525                                  * of the @ref rte_crypto_auth_xform structure. For
526                                  * physical crypto devices the caller must allocate at
527                                  * least digest_length of physically contiguous memory
528                                  * at this location.
529                                  *
530                                  * For digest generation, the digest result will
531                                  * overwrite any data at this location.
532                                  *
533                                  * @note
534                                  * For GCM (@ref RTE_CRYPTO_AEAD_AES_GCM), for
535                                  * "digest result" read "authentication tag T".
536                                  */
537                                 rte_iova_t phys_addr;
538                                 /**< Physical address of digest */
539                         } digest; /**< Digest parameters */
540                         struct {
541                                 uint8_t *data;
542                                 /**< Pointer to Additional Authenticated Data (AAD)
543                                  * needed for authenticated cipher mechanisms (CCM and
544                                  * GCM)
545                                  *
546                                  * Specifically for CCM (@ref RTE_CRYPTO_AEAD_AES_CCM),
547                                  * the caller should setup this field as follows:
548                                  *
549                                  * - the additional authentication data itself should
550                                  * be written starting at an offset of 18 bytes into
551                                  * the array, leaving room for the first block (16 bytes)
552                                  * and the length encoding in the first two bytes of the
553                                  * second block.
554                                  *
555                                  * - the array should be big enough to hold the above
556                                  * fields, plus any padding to round this up to the
557                                  * nearest multiple of the block size (16 bytes).
558                                  * Padding will be added by the implementation.
559                                  *
560                                  * - Note that PMDs may modify the memory reserved
561                                  * (first 18 bytes and the final padding).
562                                  *
563                                  * Finally, for GCM (@ref RTE_CRYPTO_AEAD_AES_GCM), the
564                                  * caller should setup this field as follows:
565                                  *
566                                  * - the AAD is written in starting at byte 0
567                                  * - the array must be big enough to hold the AAD, plus
568                                  * any space to round this up to the nearest multiple
569                                  * of the block size (16 bytes).
570                                  *
571                                  */
572                                 rte_iova_t phys_addr;   /**< physical address */
573                         } aad;
574                         /**< Additional authentication parameters */
575                 } aead;
576
577                 struct {
578                         struct {
579                                 struct {
580                                         uint32_t offset;
581                                          /**< Starting point for cipher processing,
582                                           * specified as number of bytes from start
583                                           * of data in the source buffer.
584                                           * The result of the cipher operation will be
585                                           * written back into the output buffer
586                                           * starting at this location.
587                                           *
588                                           * @note
589                                           * For SNOW 3G @ RTE_CRYPTO_CIPHER_SNOW3G_UEA2,
590                                           * KASUMI @ RTE_CRYPTO_CIPHER_KASUMI_F8
591                                           * and ZUC @ RTE_CRYPTO_CIPHER_ZUC_EEA3,
592                                           * this field should be in bits.
593                                           */
594                                         uint32_t length;
595                                          /**< The message length, in bytes, of the
596                                           * source buffer on which the cryptographic
597                                           * operation will be computed.
598                                           * This must be a multiple of the block size
599                                           * if a block cipher is being used. This is
600                                           * also the same as the result length.
601                                           *
602                                           * @note
603                                           * For SNOW 3G @ RTE_CRYPTO_AUTH_SNOW3G_UEA2,
604                                           * KASUMI @ RTE_CRYPTO_CIPHER_KASUMI_F8
605                                           * and ZUC @ RTE_CRYPTO_CIPHER_ZUC_EEA3,
606                                           * this field should be in bits.
607                                           */
608                                 } data; /**< Data offsets and length for ciphering */
609                         } cipher;
610
611                         struct {
612                                 struct {
613                                         uint32_t offset;
614                                          /**< Starting point for hash processing,
615                                           * specified as number of bytes from start of
616                                           * packet in source buffer.
617                                           *
618                                           * @note
619                                           * For SNOW 3G @ RTE_CRYPTO_AUTH_SNOW3G_UIA2,
620                                           * KASUMI @ RTE_CRYPTO_AUTH_KASUMI_F9
621                                           * and ZUC @ RTE_CRYPTO_AUTH_ZUC_EIA3,
622                                           * this field should be in bits.
623                                           *
624                                           * @note
625                                           * For KASUMI @ RTE_CRYPTO_AUTH_KASUMI_F9,
626                                           * this offset should be such that
627                                           * data to authenticate starts at COUNT.
628                                           */
629                                         uint32_t length;
630                                          /**< The message length, in bytes, of the source
631                                           * buffer that the hash will be computed on.
632                                           *
633                                           * @note
634                                           * For SNOW 3G @ RTE_CRYPTO_AUTH_SNOW3G_UIA2,
635                                           * KASUMI @ RTE_CRYPTO_AUTH_KASUMI_F9
636                                           * and ZUC @ RTE_CRYPTO_AUTH_ZUC_EIA3,
637                                           * this field should be in bits.
638                                           *
639                                           * @note
640                                           * For KASUMI @ RTE_CRYPTO_AUTH_KASUMI_F9,
641                                           * the length should include the COUNT,
642                                           * FRESH, message, direction bit and padding
643                                           * (to be multiple of 8 bits).
644                                           */
645                                 } data;
646                                 /**< Data offsets and length for authentication */
647
648                                 struct {
649                                         uint8_t *data;
650                                         /**< This points to the location where
651                                          * the digest result should be inserted
652                                          * (in the case of digest generation)
653                                          * or where the purported digest exists
654                                          * (in the case of digest verification).
655                                          *
656                                          * At session creation time, the client
657                                          * specified the digest result length with
658                                          * the digest_length member of the
659                                          * @ref rte_crypto_auth_xform structure.
660                                          * For physical crypto devices the caller
661                                          * must allocate at least digest_length of
662                                          * physically contiguous memory at this
663                                          * location.
664                                          *
665                                          * For digest generation, the digest result
666                                          * will overwrite any data at this location.
667                                          *
668                                          */
669                                         rte_iova_t phys_addr;
670                                         /**< Physical address of digest */
671                                 } digest; /**< Digest parameters */
672                         } auth;
673                 };
674         };
675 };
676
677
678 /**
679  * Reset the fields of a symmetric operation to their default values.
680  *
681  * @param       op      The crypto operation to be reset.
682  */
683 static inline void
684 __rte_crypto_sym_op_reset(struct rte_crypto_sym_op *op)
685 {
686         memset(op, 0, sizeof(*op));
687 }
688
689
690 /**
691  * Allocate space for symmetric crypto xforms in the private data space of the
692  * crypto operation. This also defaults the crypto xform type to
693  * RTE_CRYPTO_SYM_XFORM_NOT_SPECIFIED and configures the chaining of the xforms
694  * in the crypto operation
695  *
696  * @return
697  * - On success returns pointer to first crypto xform in crypto operations chain
698  * - On failure returns NULL
699  */
700 static inline struct rte_crypto_sym_xform *
701 __rte_crypto_sym_op_sym_xforms_alloc(struct rte_crypto_sym_op *sym_op,
702                 void *priv_data, uint8_t nb_xforms)
703 {
704         struct rte_crypto_sym_xform *xform;
705
706         sym_op->xform = xform = (struct rte_crypto_sym_xform *)priv_data;
707
708         do {
709                 xform->type = RTE_CRYPTO_SYM_XFORM_NOT_SPECIFIED;
710                 xform = xform->next = --nb_xforms > 0 ? xform + 1 : NULL;
711         } while (xform);
712
713         return sym_op->xform;
714 }
715
716
717 /**
718  * Attach a session to a symmetric crypto operation
719  *
720  * @param       sym_op  crypto operation
721  * @param       sess    cryptodev session
722  */
723 static inline int
724 __rte_crypto_sym_op_attach_sym_session(struct rte_crypto_sym_op *sym_op,
725                 struct rte_cryptodev_sym_session *sess)
726 {
727         sym_op->session = sess;
728
729         return 0;
730 }
731
732
733 #ifdef __cplusplus
734 }
735 #endif
736
737 #endif /* _RTE_CRYPTO_SYM_H_ */