#include <rte_crypto.h>

Data Fields
struct {
struct {
uint32_t offset
uint32_t length
} to_cipher
struct {
uint32_t offset
uint32_t length
} to_hash
}	data
struct {
uint8_t * data
size_t length
}	iv
struct {
uint8_t * data
phys_addr_t phys_addr
uint32_t length
}	digest
struct {
uint8_t * data
phys_addr_t phys_addr
uint32_t length
}	additional_auth
struct rte_mempool *	pool
void *	user_data
struct rte_mbuf *	m
uint8_t	offset
struct rte_cryptodev_session *	session
struct rte_crypto_xform *	xform

Detailed Description

Cryptographic Operation Data.

This structure contains data relating to performing cryptographic processing on a data buffer. This request is used with rte_crypto_enqueue_burst() call for performing cipher, hash, or a combined hash and cipher operations.

Definition at line 369 of file rte_crypto.h.

Field Documentation

struct rte_mbuf* m

Destination mbuf

Definition at line 374 of file rte_crypto.h.

uint8_t offset

Data offset

Definition at line 375 of file rte_crypto.h.

struct rte_cryptodev_session* session

Handle for the initialised session context

Definition at line 379 of file rte_crypto.h.

struct rte_crypto_xform* xform

Session-less API crypto operation parameters

Definition at line 381 of file rte_crypto.h.

uint32_t offset

Starting point for cipher processing, specified as number of bytes from start of data in the source buffer. The result of the cipher operation will be written back into the output buffer starting at this location.

Starting point for hash processing, specified as number of bytes from start of packet in source buffer.

Note: For CCM and GCM modes of operation, this field is ignored. The field additional_auth field should be set instead.; For AES-GMAC (RTE_CRYPTO_AUTH_AES_GMAC) mode of operation, this field specifies the start of the AAD data in the source buffer.

Definition at line 388 of file rte_crypto.h.

uint32_t length

The message length, in bytes, of the source buffer on which the cryptographic operation will be computed. This must be a multiple of the block size if a block cipher is being used. This is also the same as the result length.

Note: In the case of CCM RTE_CRYPTO_AUTH_AES_CCM, this value should not include the length of the padding or the length of the MAC; the driver will compute the actual number of bytes over which the encryption will occur, which will include these values.; For AES-GMAC RTE_CRYPTO_AUTH_AES_GMAC, this field should be set to 0.

The message length, in bytes, of the source buffer that the hash will be computed on.

Note: For CCM and GCM modes of operation, this field is ignored. The field additional_auth field should be set instead.; For AES-GMAC RTE_CRYPTO_AUTH_AES_GMAC mode of operation, this field specifies the length of the AAD data in the source buffer.

Length of digest

Examples:: l2fwd-crypto/main.c.

Definition at line 396 of file rte_crypto.h.

struct { ... } to_cipher

Data offsets and length for ciphering

Examples:: l2fwd-crypto/main.c.

struct { ... } to_hash

Data offsets and length for authentication

Examples:: l2fwd-crypto/main.c.

struct { ... } data

Details of data to be operated on

Examples:: l2fwd-crypto/main.c.

uint8_t* data

Initialisation Vector or Counter.

              - For block ciphers in CBC or F8 mode, or for Kasumi in F8
              mode, or for SNOW3G in UEA2 mode, this is the Initialisation
              Vector (IV) value.

              - For block ciphers in CTR mode, this is the counter.

              - For GCM mode, this is either the IV (if the length is 96
              bits) or J0 (for other sizes), where J0 is as defined by
              NIST SP800-38D. Regardless of the IV length, a full 16 bytes
              needs to be allocated.

              - For CCM mode, the first byte is reserved, and the nonce
              should be written starting at &iv[1] (to allow space for the
              implementation to write in the flags in the first byte).
              Note that a full 16 bytes should be allocated, even though
              the length field will have a value less than this.

              - For AES-XTS, this is the 128bit tweak, i, from IEEE Std
              1619-2007.

              For optimum performance, the data pointed to SHOULD be
              8-byte aligned.

If this member of this structure is set this is a pointer 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).

At session creation time, the client specified the digest result length with the digest_length member of the rte_crypto_auth_xform structure. For physical crypto devices the caller must allocate at least digest_length of physically contiguous memory at this location.

For digest generation, the digest result will overwrite any data at this location.

Note: For GCM (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.

Pointer to Additional Authenticated Data (AAD) needed for authenticated cipher mechanisms (CCM and GCM), and to the IV for SNOW3G authentication (RTE_CRYPTO_AUTH_SNOW3G_UIA2). For other authentication mechanisms this pointer is ignored.

The length of the data pointed to by this field is set up for the session in the rte_crypto_auth_xform structure as part of the rte_cryptodev_session_create function call. This length must not exceed 240 bytes.

Specifically for CCM (RTE_CRYPTO_AUTH_AES_CCM), the caller should setup this field as follows:

the nonce should be written starting at an offset of one byte into the array, leaving room for the implementation to write in the flags to the first byte.

the additional authentication data itself should be written starting at an offset of 18 bytes into the array, leaving room for the length encoding in the first two bytes of the second block.

the array should be big enough to hold the above fields, plus any padding to round this up to the nearest multiple of the block size (16 bytes). Padding will be added by the implementation.

Finally, for GCM (RTE_CRYPTO_AUTH_AES_GCM), the caller should setup this field as follows:

the AAD is written in starting at byte 0
the array must be big enough to hold the AAD, plus any space to round this up to the nearest multiple of the block size (16 bytes).

Note: For AES-GMAC (RTE_CRYPTO_AUTH_AES_GMAC) mode of operation, this field is not used and should be set to 0. Instead the AAD data should be placed in the source buffer.

Definition at line 451 of file rte_crypto.h.

phys_addr_t phys_addr

Physical address of digest

physical address

Examples:: l2fwd-crypto/main.c.

Definition at line 476 of file rte_crypto.h.

size_t length

Length of valid IV data.

              - For block ciphers in CBC or F8 mode, or for Kasumi in F8
              mode, or for SNOW3G in UEA2 mode, this is the length of the
              IV (which must be the same as the block length of the
              cipher).

              - For block ciphers in CTR mode, this is the length of the
              counter (which must be the same as the block length of the
              cipher).

              - For GCM mode, this is either 12 (for 96-bit IVs) or 16, in
              which case data points to J0.

              - For CCM mode, this is the length of the nonce, which can
              be in the range 7 to 13 inclusive.

Definition at line 478 of file rte_crypto.h.

struct { ... } iv

Initialisation vector parameters

Examples:: l2fwd-crypto/main.c.

struct { ... } digest

Digest parameters

Examples:: l2fwd-crypto/main.c.

struct { ... } additional_auth

Additional authentication parameters

struct rte_mempool* pool

mempool used to allocate crypto op

Definition at line 576 of file rte_crypto.h.

void* user_data

opaque pointer for user data

Definition at line 580 of file rte_crypto.h.

The documentation for this struct was generated from the following file:

lib/librte_cryptodev/rte_crypto.h

Data Fields

Detailed Description

Field Documentation