rte_crypto_sym.h(3)

πŸ’– rte_crypto_sym.h(3) πŸ’–

okay bestie, gather round, because this is the manual page for rte_crypto_sym.h β€” a whole header file full of symmetric crypto definitions, and she is serving. This is part 1 of 2, so buckle up, we're not even done yet. πŸŽ€


🌈 NAME 🌈

rte_crypto_sym.h β€” like, the file. That's her name. That's the whole vibe. πŸ’…


✨ SYNOPSIS ✨

so first you gotta pull her in, right? the include stack is giving very "I need all my friends with me":

#include <string.h>
#include <rte_compat.h>
#include <rte_mbuf.h>
#include <rte_memory.h>
#include <rte_mempool.h>
#include <rte_common.h>

πŸ¦‹ Data Structures πŸ¦‹

the cast list, the main characters, no skips:

  • struct rte_crypto_vec
  • struct rte_crypto_sgl
  • struct rte_crypto_va_iova_ptr
  • struct rte_crypto_sym_vec
  • union rte_crypto_sym_ofs
  • struct rte_crypto_cipher_xform
  • struct rte_crypto_auth_xform
  • struct rte_crypto_sym_xform
  • struct rte_crypto_sym_op

🌸 Enumerations 🌸

every single one, verbatim, because we do NOT summarize our queens:

enum rte_crypto_cipher_algorithm { RTE_CRYPTO_CIPHER_NULL = 1,
    RTE_CRYPTO_CIPHER_3DES_CBC, RTE_CRYPTO_CIPHER_3DES_CTR,
    RTE_CRYPTO_CIPHER_3DES_ECB, RTE_CRYPTO_CIPHER_AES_CBC,
    RTE_CRYPTO_CIPHER_AES_CTR, RTE_CRYPTO_CIPHER_AES_ECB,
    RTE_CRYPTO_CIPHER_AES_F8, RTE_CRYPTO_CIPHER_AES_XTS,
    RTE_CRYPTO_CIPHER_ARC4, RTE_CRYPTO_CIPHER_KASUMI_F8,
    RTE_CRYPTO_CIPHER_SNOW3G_UEA2, RTE_CRYPTO_CIPHER_ZUC_EEA3,
    RTE_CRYPTO_CIPHER_DES_CBC, RTE_CRYPTO_CIPHER_AES_DOCSISBPI,
    RTE_CRYPTO_CIPHER_DES_DOCSISBPI, RTE_CRYPTO_CIPHER_SM4_ECB,
    RTE_CRYPTO_CIPHER_SM4_CBC, RTE_CRYPTO_CIPHER_SM4_CTR,
    RTE_CRYPTO_CIPHER_SM4_OFB, RTE_CRYPTO_CIPHER_SM4_CFB,
    RTE_CRYPTO_CIPHER_SM4_XTS }
enum rte_crypto_cipher_operation { RTE_CRYPTO_CIPHER_OP_ENCRYPT,
    RTE_CRYPTO_CIPHER_OP_DECRYPT }
enum rte_crypto_auth_algorithm { RTE_CRYPTO_AUTH_NULL = 1,
    RTE_CRYPTO_AUTH_AES_CBC_MAC, RTE_CRYPTO_AUTH_AES_CMAC,
    RTE_CRYPTO_AUTH_AES_GMAC, RTE_CRYPTO_AUTH_AES_XCBC_MAC,
    RTE_CRYPTO_AUTH_KASUMI_F9, RTE_CRYPTO_AUTH_MD5,
    RTE_CRYPTO_AUTH_MD5_HMAC, RTE_CRYPTO_AUTH_SHA1,
    RTE_CRYPTO_AUTH_SHA1_HMAC, RTE_CRYPTO_AUTH_SHA224,
    RTE_CRYPTO_AUTH_SHA224_HMAC, RTE_CRYPTO_AUTH_SHA256,
    RTE_CRYPTO_AUTH_SHA256_HMAC, RTE_CRYPTO_AUTH_SHA384,
    RTE_CRYPTO_AUTH_SHA384_HMAC, RTE_CRYPTO_AUTH_SHA512,
    RTE_CRYPTO_AUTH_SHA512_HMAC, RTE_CRYPTO_AUTH_SNOW3G_UIA2,
    RTE_CRYPTO_AUTH_ZUC_EIA3, RTE_CRYPTO_AUTH_SHA3_224,
    RTE_CRYPTO_AUTH_SHA3_224_HMAC, RTE_CRYPTO_AUTH_SHA3_256,
    RTE_CRYPTO_AUTH_SHA3_256_HMAC, RTE_CRYPTO_AUTH_SHA3_384,
    RTE_CRYPTO_AUTH_SHA3_384_HMAC, RTE_CRYPTO_AUTH_SHA3_512,
    RTE_CRYPTO_AUTH_SHA3_512_HMAC, RTE_CRYPTO_AUTH_SM3,
    RTE_CRYPTO_AUTH_SHAKE_128, RTE_CRYPTO_AUTH_SHAKE_256,
    RTE_CRYPTO_AUTH_SM3_HMAC }
enum rte_crypto_auth_operation { RTE_CRYPTO_AUTH_OP_VERIFY,
    RTE_CRYPTO_AUTH_OP_GENERATE }
enum rte_crypto_aead_algorithm { RTE_CRYPTO_AEAD_AES_CCM = 1,
    RTE_CRYPTO_AEAD_AES_GCM, RTE_CRYPTO_AEAD_CHACHA20_POLY1305,
    RTE_CRYPTO_AEAD_SM4_GCM }
enum rte_crypto_aead_operation { RTE_CRYPTO_AEAD_OP_ENCRYPT,
    RTE_CRYPTO_AEAD_OP_DECRYPT }
enum rte_crypto_sym_xform_type { RTE_CRYPTO_SYM_XFORM_NOT_SPECIFIED = 0,
    RTE_CRYPTO_SYM_XFORM_AUTH, RTE_CRYPTO_SYM_XFORM_CIPHER,
    RTE_CRYPTO_SYM_XFORM_AEAD }

πŸ‘‘ Functions πŸ‘‘

watch her do her little signature moves:

static void __rte_crypto_sym_op_reset (struct rte_crypto_sym_op *op)
static struct rte_crypto_sym_xform *
    __rte_crypto_sym_op_sym_xforms_alloc (struct rte_crypto_sym_op
    *sym_op, void *priv_data, uint8_t nb_xforms)
static int __rte_crypto_sym_op_attach_sym_session (struct
    rte_crypto_sym_op *sym_op, void *sess)
static __rte_experimental int rte_crypto_mbuf_to_vec (const struct
    rte_mbuf *mb, uint32_t ofs, uint32_t len, struct rte_crypto_vec
    vec[], uint32_t num)
heads up bestie: rte_crypto_mbuf_to_vec is marked __rte_experimental, so she's still in her experimental era. πŸ™ˆ

⭐ Variables ⭐

the string tables, our beloved little label-makers:

  • const char * rte_crypto_cipher_operation_strings []
  • const char * rte_crypto_auth_operation_strings []
  • const char * rte_crypto_aead_operation_strings []

πŸ’œ Detailed Description πŸ’œ

RTE Definitions for Symmetric Cryptography

so like, this header defines the symmetric cipher and authentication algorithms and modes, plus all the supported symmetric crypto operation combinations. it's the whole aesthetic, both the algorithms and how you're allowed to combine them. 🌈

Definition in file rte_crypto_sym.h.


🧚 Enumeration Type Documentation 🧚

πŸ’– enum rte_crypto_cipher_algorithm πŸ’–

Symmetric Cipher Algorithms

okay before we get into the list, there's a rule here and it's giving "don't touch the display or the whole shelf falls over":

Note, to avoid ABI breakage across releases
  • LIST_END should not be added to this enum
  • the order of enums should not be changed
  • new algorithms should only be added to the end

fr fr. no cap. respect the order. 🌸

Enumerator

  • RTE_CRYPTO_CIPHER_NULL β€” NULL cipher algorithm. No mode applies to the NULL algorithm.
  • RTE_CRYPTO_CIPHER_3DES_CBC β€” Triple DES algorithm in CBC mode
  • RTE_CRYPTO_CIPHER_3DES_CTR β€” Triple DES algorithm in CTR mode
  • RTE_CRYPTO_CIPHER_3DES_ECB β€” Triple DES algorithm in ECB mode
  • RTE_CRYPTO_CIPHER_AES_CBC β€” AES algorithm in CBC mode
  • RTE_CRYPTO_CIPHER_AES_CTR β€” AES algorithm in Counter mode
  • RTE_CRYPTO_CIPHER_AES_ECB β€” AES algorithm in ECB mode
  • RTE_CRYPTO_CIPHER_AES_F8 β€” AES algorithm in F8 mode
  • RTE_CRYPTO_CIPHER_AES_XTS β€” AES algorithm in XTS mode
  • RTE_CRYPTO_CIPHER_ARC4 β€” (A)RC4 cipher algorithm
  • RTE_CRYPTO_CIPHER_KASUMI_F8 β€” KASUMI algorithm in F8 mode
  • RTE_CRYPTO_CIPHER_SNOW3G_UEA2 β€” SNOW 3G algorithm in UEA2 mode
  • RTE_CRYPTO_CIPHER_ZUC_EEA3 β€” ZUC algorithm in EEA3 mode
  • RTE_CRYPTO_CIPHER_DES_CBC β€” DES algorithm in CBC mode
  • RTE_CRYPTO_CIPHER_AES_DOCSISBPI β€” AES algorithm using modes required by DOCSIS Baseline Privacy Plus Spec. Chained mbufs are not supported in this mode, i.e. rte_mbuf.next for m_src and m_dst in the rte_crypto_sym_op must be NULL.
  • RTE_CRYPTO_CIPHER_DES_DOCSISBPI β€” DES algorithm using modes required by DOCSIS Baseline Privacy Plus Spec. Chained mbufs are not supported in this mode, i.e. rte_mbuf.next for m_src and m_dst in the rte_crypto_sym_op must be NULL.
  • RTE_CRYPTO_CIPHER_SM4_ECB β€” ShangMi 4 (SM4) algorithm in ECB mode
  • RTE_CRYPTO_CIPHER_SM4_CBC β€” ShangMi 4 (SM4) algorithm in CBC mode
  • RTE_CRYPTO_CIPHER_SM4_CTR β€” ShangMi 4 (SM4) algorithm in CTR mode
  • RTE_CRYPTO_CIPHER_SM4_OFB β€” ShangMi 4 (SM4) algorithm in OFB mode
  • RTE_CRYPTO_CIPHER_SM4_CFB β€” ShangMi 4 (SM4) algorithm in CFB mode
  • RTE_CRYPTO_CIPHER_SM4_XTS β€” ShangMi 4 (SM4) algorithm in XTS mode

Definition at line 120 of file rte_crypto_sym.h.


🌟 enum rte_crypto_cipher_operation 🌟

Symmetric Cipher Direction

which way are we going, bestie, and be honest:

Enumerator

  • RTE_CRYPTO_CIPHER_OP_ENCRYPT β€” Encrypt cipher operation
  • RTE_CRYPTO_CIPHER_OP_DECRYPT β€” Decrypt cipher operation

Definition at line 186 of file rte_crypto_sym.h.


πŸŽ€ enum rte_crypto_auth_algorithm πŸŽ€

Symmetric Authentication / Hash Algorithms

same energy as before, the ABI is fragile and we protect her:

Note, to avoid ABI breakage across releases
  • LIST_END should not be added to this enum
  • the order of enums should not be changed
  • new algorithms should only be added to the end

Enumerator

  • RTE_CRYPTO_AUTH_NULL β€” NULL hash algorithm.
  • RTE_CRYPTO_AUTH_AES_CBC_MAC β€” AES-CBC-MAC algorithm. Only 128-bit keys are supported.
  • RTE_CRYPTO_AUTH_AES_CMAC β€” AES CMAC algorithm.
  • RTE_CRYPTO_AUTH_AES_GMAC β€” AES GMAC algorithm.
  • RTE_CRYPTO_AUTH_AES_XCBC_MAC β€” AES XCBC algorithm.
  • RTE_CRYPTO_AUTH_KASUMI_F9 β€” KASUMI algorithm in F9 mode.
  • RTE_CRYPTO_AUTH_MD5 β€” MD5 algorithm
  • RTE_CRYPTO_AUTH_MD5_HMAC β€” HMAC using MD5 algorithm
  • RTE_CRYPTO_AUTH_SHA1 β€” 160 bit SHA algorithm.
  • RTE_CRYPTO_AUTH_SHA1_HMAC β€” HMAC using 160 bit SHA algorithm. HMAC-SHA-1-96 can be generated by setting digest_length to 12 bytes in auth/aead xforms.
  • RTE_CRYPTO_AUTH_SHA224 β€” 224 bit SHA algorithm.
  • RTE_CRYPTO_AUTH_SHA224_HMAC β€” HMAC using 224 bit SHA algorithm.
  • RTE_CRYPTO_AUTH_SHA256 β€” 256 bit SHA algorithm.
  • RTE_CRYPTO_AUTH_SHA256_HMAC β€” HMAC using 256 bit SHA algorithm.
  • RTE_CRYPTO_AUTH_SHA384 β€” 384 bit SHA algorithm.
  • RTE_CRYPTO_AUTH_SHA384_HMAC β€” HMAC using 384 bit SHA algorithm.
  • RTE_CRYPTO_AUTH_SHA512 β€” 512 bit SHA algorithm.
  • RTE_CRYPTO_AUTH_SHA512_HMAC β€” HMAC using 512 bit SHA algorithm.
  • RTE_CRYPTO_AUTH_SNOW3G_UIA2 β€” SNOW 3G algorithm in UIA2 mode.
  • RTE_CRYPTO_AUTH_ZUC_EIA3 β€” ZUC algorithm in EIA3 mode
  • RTE_CRYPTO_AUTH_SHA3_224 β€” 224 bit SHA3 algorithm.
  • RTE_CRYPTO_AUTH_SHA3_224_HMAC β€” HMAC using 224 bit SHA3 algorithm.
  • RTE_CRYPTO_AUTH_SHA3_256 β€” 256 bit SHA3 algorithm.
  • RTE_CRYPTO_AUTH_SHA3_256_HMAC β€” HMAC using 256 bit SHA3 algorithm.
  • RTE_CRYPTO_AUTH_SHA3_384 β€” 384 bit SHA3 algorithm.
  • RTE_CRYPTO_AUTH_SHA3_384_HMAC β€” HMAC using 384 bit SHA3 algorithm.
  • RTE_CRYPTO_AUTH_SHA3_512 β€” 512 bit SHA3 algorithm.
  • RTE_CRYPTO_AUTH_SHA3_512_HMAC β€” HMAC using 512 bit SHA3 algorithm.
  • RTE_CRYPTO_AUTH_SM3 β€” ShangMi 3 (SM3) algorithm
  • RTE_CRYPTO_AUTH_SHAKE_128 β€” 128 bit SHAKE algorithm.
  • RTE_CRYPTO_AUTH_SHAKE_256 β€” 256 bit SHAKE algorithm.

Definition at line 311 of file rte_crypto_sym.h.


πŸ”₯ enum rte_crypto_auth_operation πŸ”₯

Symmetric Authentication / Hash Operations

Enumerator

  • RTE_CRYPTO_AUTH_OP_VERIFY β€” Verify authentication digest
  • RTE_CRYPTO_AUTH_OP_GENERATE β€” Generate authentication digest

Definition at line 390 of file rte_crypto_sym.h.


🫢 enum rte_crypto_aead_algorithm 🫢

Symmetric AEAD Algorithms

you already know the rules by now, but here they are again because consistency is iconic:

Note, to avoid ABI breakage across releases
  • LIST_END should not be added to this enum
  • the order of enums should not be changed
  • new algorithms should only be added to the end

Enumerator

  • RTE_CRYPTO_AEAD_AES_CCM β€” AES algorithm in CCM mode.
  • RTE_CRYPTO_AEAD_AES_GCM β€” AES algorithm in GCM mode.
  • RTE_CRYPTO_AEAD_CHACHA20_POLY1305 β€” Chacha20 cipher with poly1305 authenticator
  • RTE_CRYPTO_AEAD_SM4_GCM β€” SM4 cipher in GCM mode

Definition at line 480 of file rte_crypto_sym.h.


πŸ’€ enum rte_crypto_aead_operation πŸ’€

Symmetric AEAD Operations

Enumerator

  • RTE_CRYPTO_AEAD_OP_ENCRYPT β€” Encrypt and generate digest
  • RTE_CRYPTO_AEAD_OP_DECRYPT β€” Verify digest and decrypt

Definition at line 492 of file rte_crypto_sym.h.


🌈 enum rte_crypto_sym_xform_type 🌈

Crypto transformation types

Enumerator

  • RTE_CRYPTO_SYM_XFORM_NOT_SPECIFIED β€” No xform specified
  • RTE_CRYPTO_SYM_XFORM_AUTH β€” Authentication xform
  • RTE_CRYPTO_SYM_XFORM_CIPHER β€” Cipher xform
  • RTE_CRYPTO_SYM_XFORM_AEAD β€” AEAD xform

Definition at line 564 of file rte_crypto_sym.h.


okay and that's only part one, bestie β€” she keeps going. πŸ’…βœ¨

πŸ’– Function Documentation πŸ’–


🫢 __rte_crypto_sym_op_reset

void __rte_crypto_sym_op_reset (struct rte_crypto_sym_op * op)

okay so this lil guy is [inline] and [static], and what it does is reset the fields of a symmetric operation back to their default values. like a little factory-reset button for your op, no cap. πŸ”„

Parameters

  • op β€” the crypto operation you wanna reset. that's it, that's the whole job.

Definition at line 887 of file rte_crypto_sym.h.


🌸 __rte_crypto_sym_op_sym_xforms_alloc

struct rte_crypto_sym_xform * __rte_crypto_sym_op_sym_xforms_alloc (struct rte_crypto_sym_op * sym_op, void * priv_data, uint8_t nb_xforms)

also [inline], also [static], and bestie this one is a whole moment. it allocates space for symmetric crypto xforms inside the private data space of the crypto operation. and not only that β€” it also defaults the crypto xform type to RTE_CRYPTO_SYM_XFORM_NOT_SPECIFIED and configures the chaining of the xforms in the crypto operation. multitasking queen πŸ‘‘

Returns

  • on success, you get a pointer to the first crypto xform in the crypto operations chain πŸŽ‰
  • on failure, you get NULL 😭

Definition at line 904 of file rte_crypto_sym.h.


πŸ¦‹ __rte_crypto_sym_op_attach_sym_session

int __rte_crypto_sym_op_attach_sym_session (struct rte_crypto_sym_op * sym_op, void * sess)

[inline] + [static] again (the trio really said consistency ✨). this one attaches a session to a symmetric crypto operation. basically matchmaking but for ops and sessions πŸ’…

Parameters

  • sym_op β€” the crypto operation.
  • sess β€” the cryptodev session.

Definition at line 927 of file rte_crypto_sym.h.


🌈 rte_crypto_mbuf_to_vec

__rte_experimental int rte_crypto_mbuf_to_vec (const struct rte_mbuf * mb, uint32_t ofs, uint32_t len, struct rte_crypto_vec vec[], uint32_t num)

s[inline], [static], and heads up β€” it's tagged __rte_experimental, so treat it like a new drop that might still change πŸ‘€

what it does: converts a portion of mbuf data into a vector representation. each segment gets its own separate entry in the vec array. it expects that the ofs + len you gave it does not exceed the mbuf's pkt_len. it's giving strict boundaries, honestly.

Parameters

  • mb β€” pointer to the rte_mbuf object.
  • ofs β€” offset within mbuf data to start with.
  • len β€” length of data to represent.
  • vec β€” pointer to an output array of IO vectors.
  • num β€” size of an output array.

Returns

  • the number of successfully filled entries in the vec array 🌟
  • a negative number of elements in the vec array required (so it can also tell you "girl you didn't give me enough room" πŸ’€)

Definition at line 954 of file rte_crypto_sym.h.


πŸŽ€ Variable Documentation πŸŽ€

  • const char* rte_crypto_cipher_operation_strings[] [extern] β€” cipher operation name strings πŸ’œ
  • const char* rte_crypto_auth_operation_strings[] [extern] β€” authentication operation name strings πŸ’œ
  • const char* rte_crypto_aead_operation_strings[] [extern] β€” authentication operation name strings πŸ’œ (yes bestie, it says authentication for the aead one too β€” that's literally what the page says, we don't question the source, we just report fr fr πŸ™ˆ)

πŸ‘‘ Author

Generated automatically by Doxygen for DPDK from the source code. so technically the author is a robot and the robot ate, periodt πŸ€–βœ¨


okay and that's a wrap on this whole page πŸ’– this was DPDK Version 25.11.3, page rte_crypto_sym.h(3) β€” go forth, attach your sessions, allocate your xforms, and slay πŸ«ΆπŸŽ€

πŸ“¦ where this page comes from