X-Git-Url: http://git.droids-corp.org/?a=blobdiff_plain;f=lib%2Flibrte_cryptodev%2Frte_crypto_sym.h;h=f29c98051f967157089df029ae52678393ad9aea;hb=6857fdaff5ee93de0b12f407f5dceb2f433b5aa2;hp=9e887c110cdab5362a25863823a0ae59668db1b8;hpb=32f9289dd44f7e7a0979304c799d2114862b45b2;p=dpdk.git

diff --git a/lib/librte_cryptodev/rte_crypto_sym.h b/lib/librte_cryptodev/rte_crypto_sym.h
index 9e887c110c..f29c98051f 100644
--- a/lib/librte_cryptodev/rte_crypto_sym.h
+++ b/lib/librte_cryptodev/rte_crypto_sym.h
@@ -269,9 +269,12 @@ enum rte_crypto_auth_algorithm {
 	/**< HMAC using MD5 algorithm */
 
 	RTE_CRYPTO_AUTH_SHA1,
-	/**< 128 bit SHA algorithm. */
+	/**< 160 bit SHA algorithm. */
 	RTE_CRYPTO_AUTH_SHA1_HMAC,
-	/**< HMAC using 128 bit SHA algorithm. */
+	/**< 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,
@@ -409,6 +412,8 @@ enum rte_crypto_aead_algorithm {
 	/**< 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_LIST_END
 };
 
@@ -452,6 +457,11 @@ struct rte_crypto_aead_xform {
 		 * be allocated, even though the length field will
 		 * have a value less than this.
 		 *
+		 * - For Chacha20-Poly1305 it is 96-bit nonce.
+		 * PMD sets initial counter for Poly1305 key generation
+		 * part to 0 and for Chacha20 encryption to 1 as per
+		 * rfc8439 2.8. AEAD construction.
+		 *
 		 * For optimum performance, the data pointed to SHOULD
 		 * be 8-byte aligned.
 		 */
@@ -468,6 +478,8 @@ struct rte_crypto_aead_xform {
 		 *
 		 * - For CCM mode, this is the length of the nonce,
 		 * which can be in the range 7 to 13 inclusive.
+		 *
+		 * - For Chacha20-Poly1305 this field is always 12.
 		 */
 	} iv;	/**< Initialisation vector parameters */
 
@@ -693,6 +705,14 @@ struct rte_crypto_sym_op {
 					  * For KASUMI @ RTE_CRYPTO_AUTH_KASUMI_F9,
 					  * this offset should be such that
 					  * data to authenticate starts at COUNT.
+					  *
+					  * @note
+					  * For DOCSIS security protocol, this
+					  * offset is the DOCSIS header length
+					  * and, therefore, also the CRC offset
+					  * i.e. the number of bytes into the
+					  * packet at which CRC calculation
+					  * should begin.
 					  */
 					uint32_t length;
 					 /**< The message length, in bytes, of the source
@@ -711,6 +731,12 @@ struct rte_crypto_sym_op {
 					  * the length should include the COUNT,
 					  * FRESH, message, direction bit and padding
 					  * (to be multiple of 8 bits).
+					  *
+					  * @note
+					  * For DOCSIS security protocol, this
+					  * is the CRC length i.e. the number of
+					  * bytes in the packet over which the
+					  * CRC should be calculated
 					  */
 				} data;
 				/**< Data offsets and length for authentication */