DPDK
22.11.7-rc1
|
#include <rte_crypto_sym.h>
Data Fields | |
struct rte_mbuf * | m_src |
struct rte_mbuf * | m_dst |
void * | session |
struct rte_crypto_sym_xform * | xform |
uint32_t | offset |
uint32_t | length |
struct { | |
uint32_t offset | |
uint32_t length | |
} | data |
uint8_t * | data |
rte_iova_t | phys_addr |
struct { | |
uint8_t * data | |
rte_iova_t phys_addr | |
} | digest |
struct { | |
uint8_t * data | |
rte_iova_t phys_addr | |
} | aad |
struct { | |
uint32_t offset | |
uint32_t length | |
} | data |
struct { | |
uint32_t offset | |
uint32_t length | |
} | data |
struct { | |
uint8_t * data | |
rte_iova_t phys_addr | |
} | digest |
Symmetric Cryptographic Operation.
This structure contains data relating to performing symmetric cryptographic processing on a referenced mbuf data buffer.
When a symmetric crypto operation is enqueued with the device for processing 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.
Definition at line 626 of file rte_crypto_sym.h.
struct rte_mbuf* m_src |
source mbuf
Definition at line 627 of file rte_crypto_sym.h.
struct rte_mbuf* m_dst |
destination mbuf
Definition at line 628 of file rte_crypto_sym.h.
void* session |
Handle for the initialised crypto/security session context
Definition at line 632 of file rte_crypto_sym.h.
struct rte_crypto_sym_xform* xform |
Session-less API crypto operation parameters
Definition at line 634 of file rte_crypto_sym.h.
uint32_t offset |
Starting point for AEAD processing, specified as number of bytes from start of packet in source buffer.
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.
Definition at line 642 of file rte_crypto_sym.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
The message length, in bytes, of the source buffer on which the cryptographic operation will be computed. This is also the same as the result length. This must be a multiple of the block size or a multiple of data-unit length as described in xform.
The message length, in bytes, of the source buffer that the hash will be computed on.
Definition at line 647 of file rte_crypto_sym.h.
struct { ... } data |
Data offsets and length for AEAD
uint8_t* data |
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).
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.
Pointer to Additional Authenticated Data (AAD) needed for authenticated cipher mechanisms (CCM and GCM)
Specifically for CCM (RTE_CRYPTO_AEAD_AES_CCM), the caller should setup this field as follows:
Finally, for GCM (RTE_CRYPTO_AEAD_AES_GCM), the caller should setup this field as follows:
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).
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).
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, that for security reasons, it is PMDs' responsibility to not leave an unencrypted digest in any buffer after performing auth-cipher operations.
Definition at line 654 of file rte_crypto_sym.h.
rte_iova_t phys_addr |
struct { ... } digest |
Digest parameters
struct { ... } aad |
Additional authentication parameters
struct { ... } data |
Data offsets and length for ciphering
struct { ... } data |
Data offsets and length for authentication
struct { ... } digest |
Digest parameters