RTE_CRYPTO_CIPHER_ZUC_EEA3,
/**< ZUC algorithm in EEA3 mode */
+ RTE_CRYPTO_CIPHER_DES_CBC,
+ /**< DES algorithm in CBC mode */
+
RTE_CRYPTO_CIPHER_LIST_END
+
};
+/** Cipher algorithm name strings */
+extern const char *
+rte_crypto_cipher_algorithm_strings[];
+
/** Symmetric Cipher Direction */
enum rte_crypto_cipher_operation {
RTE_CRYPTO_CIPHER_OP_ENCRYPT,
/**< Decrypt cipher operation */
};
+/** Cipher operation name strings */
+extern const char *
+rte_crypto_cipher_operation_strings[];
+
/**
* Symmetric Cipher Setup Data.
*
RTE_CRYPTO_AUTH_LIST_END
};
+/** Authentication algorithm name strings */
+extern const char *
+rte_crypto_auth_algorithm_strings[];
+
/** Symmetric Authentication / Hash Operations */
enum rte_crypto_auth_operation {
RTE_CRYPTO_AUTH_OP_VERIFY, /**< Verify authentication digest */
RTE_CRYPTO_AUTH_OP_GENERATE /**< Generate authentication digest */
};
+/** Authentication operation name strings */
+extern const char *
+rte_crypto_auth_operation_strings[];
+
/**
* Authentication / Hash transform data.
*
* it must have a valid *rte_mbuf* structure attached, via m_src parameter,
* which contains the source data which the crypto operation is to be performed
* on.
+ * While the mbuf is in use by a crypto operation no part of the mbuf should be
+ * changed by the application as the device may read or write to any part of the
+ * mbuf. In the case of hardware crypto devices some or all of the mbuf
+ * may be DMAed in and out of the device, so writing over the original data,
+ * though only the part specified by the rte_crypto_sym_op for transformation
+ * will be changed.
+ * Out-of-place (OOP) operation, where the source mbuf is different to the
+ * destination mbuf, is a special case. Data will be copied from m_src to m_dst.
+ * The part copied includes all the parts of the source mbuf that will be
+ * operated on, based on the cipher.data.offset+cipher.data.length and
+ * auth.data.offset+auth.data.length values in the rte_crypto_sym_op. The part
+ * indicated by the cipher parameters will be transformed, any extra data around
+ * this indicated by the auth parameters will be copied unchanged from source to
+ * destination mbuf.
+ * Also in OOP operation the cipher.data.offset and auth.data.offset apply to
+ * both source and destination mbufs. As these offsets are relative to the
+ * data_off parameter in each mbuf this can result in the data written to the
+ * destination buffer being at a different alignment, relative to buffer start,
+ * to the data in the source buffer.
*/
struct rte_crypto_sym_op {
struct rte_mbuf *m_src; /**< source mbuf */
struct {
uint8_t *data;
- /**< If this member of this structure is set this is a
- * pointer to the location where the digest result
+ /**< This points to the location where the digest result
* should be inserted (in the case of digest generation)
* or where the purported digest exists (in the case of
* digest verification).
* @note
* For GCM (@ref RTE_CRYPTO_AUTH_AES_GCM), for
* "digest result" read "authentication tag T".
- *
- * If this member is not set the digest result is
- * understood to be in the destination buffer for
- * digest generation, and in the source buffer for
- * digest verification. The location of the digest
- * result in this case is immediately following the
- * region over which the digest is computed.
*/
phys_addr_t phys_addr;
/**< Physical address of digest */