DPDK  19.08.0-rc0
Data Fields
rte_crypto_sym_op Struct Reference

#include <rte_crypto_sym.h>

Data Fields

struct rte_mbufm_src
 
struct rte_mbufm_dst
 
struct rte_cryptodev_sym_sessionsession
 
struct rte_crypto_sym_xformxform
 
struct rte_security_session * sec_session
 
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
 

Detailed Description

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.

Examples
examples/fips_validation/fips_dev_self_test.c, examples/fips_validation/main.c, examples/ipsec-secgw/esp.c, and examples/ipsec-secgw/ipsec.c.

Definition at line 487 of file rte_crypto_sym.h.

Field Documentation

◆ m_src

struct rte_mbuf* m_src

◆ m_dst

struct rte_mbuf* m_dst

destination mbuf

Definition at line 489 of file rte_crypto_sym.h.

◆ session

struct rte_cryptodev_sym_session* session

Handle for the initialised session context

Examples
examples/fips_validation/fips_dev_self_test.c.

Definition at line 493 of file rte_crypto_sym.h.

◆ xform

struct rte_crypto_sym_xform* xform

Session-less API crypto operation parameters

Examples
examples/fips_validation/main.c.

Definition at line 495 of file rte_crypto_sym.h.

◆ sec_session

struct rte_security_session* sec_session

Handle for the initialised security session context

Definition at line 497 of file rte_crypto_sym.h.

◆ offset

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.

Note
For SNOW 3G @ RTE_CRYPTO_CIPHER_SNOW3G_UEA2, KASUMI @ RTE_CRYPTO_CIPHER_KASUMI_F8 and ZUC @ RTE_CRYPTO_CIPHER_ZUC_EEA3, this field should be in bits.

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

Note
For SNOW 3G @ RTE_CRYPTO_AUTH_SNOW3G_UIA2, KASUMI @ RTE_CRYPTO_AUTH_KASUMI_F9 and ZUC @ RTE_CRYPTO_AUTH_ZUC_EIA3, this field should be in bits.
For KASUMI @ RTE_CRYPTO_AUTH_KASUMI_F9, this offset should be such that data to authenticate starts at COUNT.

Definition at line 505 of file rte_crypto_sym.h.

◆ length

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 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
For SNOW 3G @ RTE_CRYPTO_AUTH_SNOW3G_UEA2, KASUMI @ RTE_CRYPTO_CIPHER_KASUMI_F8 and ZUC @ RTE_CRYPTO_CIPHER_ZUC_EEA3, this field should be in bits.

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

Note
For SNOW 3G @ RTE_CRYPTO_AUTH_SNOW3G_UIA2, KASUMI @ RTE_CRYPTO_AUTH_KASUMI_F9 and ZUC @ RTE_CRYPTO_AUTH_ZUC_EIA3, this field should be in bits.
For KASUMI @ RTE_CRYPTO_AUTH_KASUMI_F9, the length should include the COUNT, FRESH, message, direction bit and padding (to be multiple of 8 bits).

Definition at line 510 of file rte_crypto_sym.h.

◆ data [1/4]

struct { ... } data

Data offsets and length for AEAD

◆ data [2/4]

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.

Note
For GCM (RTE_CRYPTO_AEAD_AES_GCM), for "digest result" read "authentication tag T".

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:

  • the additional authentication data itself should be written starting at an offset of 18 bytes into the array, leaving room for the first block (16 bytes) and 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.
  • Note that PMDs may modify the memory reserved (first 18 bytes and the final padding).

Finally, for GCM (RTE_CRYPTO_AEAD_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).

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.

Definition at line 517 of file rte_crypto_sym.h.

◆ phys_addr

rte_iova_t phys_addr

Physical address of digest

physical address

Definition at line 537 of file rte_crypto_sym.h.

◆ digest [1/2]

struct { ... } digest

Digest parameters

◆ aad

struct { ... } aad

Additional authentication parameters

◆ data [3/4]

struct { ... } data

Data offsets and length for ciphering

◆ data [4/4]

struct { ... } data

Data offsets and length for authentication

◆ digest [2/2]

struct { ... } digest

Digest parameters


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