1.. SPDX-License-Identifier: BSD-3-Clause 2 Copyright(c) 2016-2017 Intel Corporation. 3 4Cryptography Device Library 5=========================== 6 7The cryptodev library provides a Crypto device framework for management and 8provisioning of hardware and software Crypto poll mode drivers, defining generic 9APIs which support a number of different Crypto operations. The framework 10currently only supports cipher, authentication, chained cipher/authentication 11and AEAD symmetric Crypto operations. 12 13 14Design Principles 15----------------- 16 17The cryptodev library follows the same basic principles as those used in DPDKs 18Ethernet Device framework. The Crypto framework provides a generic Crypto device 19framework which supports both physical (hardware) and virtual (software) Crypto 20devices as well as a generic Crypto API which allows Crypto devices to be 21managed and configured and supports Crypto operations to be provisioned on 22Crypto poll mode driver. 23 24 25Device Management 26----------------- 27 28Device Creation 29~~~~~~~~~~~~~~~ 30 31Physical Crypto devices are discovered during the PCI probe/enumeration of the 32EAL function which is executed at DPDK initialization, based on 33their PCI device identifier, each unique PCI BDF (bus/bridge, device, 34function). Specific physical Crypto devices, like other physical devices in DPDK 35can be white-listed or black-listed using the EAL command line options. 36 37Virtual devices can be created by two mechanisms, either using the EAL command 38line options or from within the application using an EAL API directly. 39 40From the command line using the --vdev EAL option 41 42.. code-block:: console 43 44 --vdev 'crypto_aesni_mb0,max_nb_queue_pairs=2,max_nb_sessions=1024,socket_id=0' 45 46.. Note:: 47 48 * If DPDK application requires multiple software crypto PMD devices then required 49 number of ``--vdev`` with appropriate libraries are to be added. 50 51 * An Application with crypto PMD instaces sharing the same library requires unique ID. 52 53 Example: ``--vdev 'crypto_aesni_mb0' --vdev 'crypto_aesni_mb1'`` 54 55Our using the rte_vdev_init API within the application code. 56 57.. code-block:: c 58 59 rte_vdev_init("crypto_aesni_mb", 60 "max_nb_queue_pairs=2,max_nb_sessions=1024,socket_id=0") 61 62All virtual Crypto devices support the following initialization parameters: 63 64* ``max_nb_queue_pairs`` - maximum number of queue pairs supported by the device. 65* ``max_nb_sessions`` - maximum number of sessions supported by the device 66* ``socket_id`` - socket on which to allocate the device resources on. 67 68 69Device Identification 70~~~~~~~~~~~~~~~~~~~~~ 71 72Each device, whether virtual or physical is uniquely designated by two 73identifiers: 74 75- A unique device index used to designate the Crypto device in all functions 76 exported by the cryptodev API. 77 78- A device name used to designate the Crypto device in console messages, for 79 administration or debugging purposes. For ease of use, the port name includes 80 the port index. 81 82 83Device Configuration 84~~~~~~~~~~~~~~~~~~~~ 85 86The configuration of each Crypto device includes the following operations: 87 88- Allocation of resources, including hardware resources if a physical device. 89- Resetting the device into a well-known default state. 90- Initialization of statistics counters. 91 92The rte_cryptodev_configure API is used to configure a Crypto device. 93 94.. code-block:: c 95 96 int rte_cryptodev_configure(uint8_t dev_id, 97 struct rte_cryptodev_config *config) 98 99The ``rte_cryptodev_config`` structure is used to pass the configuration 100parameters for socket selection and number of queue pairs. 101 102.. code-block:: c 103 104 struct rte_cryptodev_config { 105 int socket_id; 106 /**< Socket to allocate resources on */ 107 uint16_t nb_queue_pairs; 108 /**< Number of queue pairs to configure on device */ 109 }; 110 111 112Configuration of Queue Pairs 113~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 114 115Each Crypto devices queue pair is individually configured through the 116``rte_cryptodev_queue_pair_setup`` API. 117Each queue pairs resources may be allocated on a specified socket. 118 119.. code-block:: c 120 121 int rte_cryptodev_queue_pair_setup(uint8_t dev_id, uint16_t queue_pair_id, 122 const struct rte_cryptodev_qp_conf *qp_conf, 123 int socket_id) 124 125 struct rte_cryptodev_qp_conf { 126 uint32_t nb_descriptors; /**< Number of descriptors per queue pair */ 127 }; 128 129 130Logical Cores, Memory and Queues Pair Relationships 131~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 132 133The Crypto device Library as the Poll Mode Driver library support NUMA for when 134a processor’s logical cores and interfaces utilize its local memory. Therefore 135Crypto operations, and in the case of symmetric Crypto operations, the session 136and the mbuf being operated on, should be allocated from memory pools created 137in the local memory. The buffers should, if possible, remain on the local 138processor to obtain the best performance results and buffer descriptors should 139be populated with mbufs allocated from a mempool allocated from local memory. 140 141The run-to-completion model also performs better, especially in the case of 142virtual Crypto devices, if the Crypto operation and session and data buffer is 143in local memory instead of a remote processor's memory. This is also true for 144the pipe-line model provided all logical cores used are located on the same 145processor. 146 147Multiple logical cores should never share the same queue pair for enqueuing 148operations or dequeuing operations on the same Crypto device since this would 149require global locks and hinder performance. It is however possible to use a 150different logical core to dequeue an operation on a queue pair from the logical 151core which it was enqueued on. This means that a crypto burst enqueue/dequeue 152APIs are a logical place to transition from one logical core to another in a 153packet processing pipeline. 154 155 156Device Features and Capabilities 157--------------------------------- 158 159Crypto devices define their functionality through two mechanisms, global device 160features and algorithm capabilities. Global devices features identify device 161wide level features which are applicable to the whole device such as 162the device having hardware acceleration or supporting symmetric Crypto 163operations, 164 165The capabilities mechanism defines the individual algorithms/functions which 166the device supports, such as a specific symmetric Crypto cipher, 167authentication operation or Authenticated Encryption with Associated Data 168(AEAD) operation. 169 170 171Device Features 172~~~~~~~~~~~~~~~ 173 174Currently the following Crypto device features are defined: 175 176* Symmetric Crypto operations 177* Asymmetric Crypto operations 178* Chaining of symmetric Crypto operations 179* SSE accelerated SIMD vector operations 180* AVX accelerated SIMD vector operations 181* AVX2 accelerated SIMD vector operations 182* AESNI accelerated instructions 183* Hardware off-load processing 184 185 186Device Operation Capabilities 187~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 188 189Crypto capabilities which identify particular algorithm which the Crypto PMD 190supports are defined by the operation type, the operation transform, the 191transform identifier and then the particulars of the transform. For the full 192scope of the Crypto capability see the definition of the structure in the 193*DPDK API Reference*. 194 195.. code-block:: c 196 197 struct rte_cryptodev_capabilities; 198 199Each Crypto poll mode driver defines its own private array of capabilities 200for the operations it supports. Below is an example of the capabilities for a 201PMD which supports the authentication algorithm SHA1_HMAC and the cipher 202algorithm AES_CBC. 203 204.. code-block:: c 205 206 static const struct rte_cryptodev_capabilities pmd_capabilities[] = { 207 { /* SHA1 HMAC */ 208 .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC, 209 .sym = { 210 .xform_type = RTE_CRYPTO_SYM_XFORM_AUTH, 211 .auth = { 212 .algo = RTE_CRYPTO_AUTH_SHA1_HMAC, 213 .block_size = 64, 214 .key_size = { 215 .min = 64, 216 .max = 64, 217 .increment = 0 218 }, 219 .digest_size = { 220 .min = 12, 221 .max = 12, 222 .increment = 0 223 }, 224 .aad_size = { 0 }, 225 .iv_size = { 0 } 226 } 227 } 228 }, 229 { /* AES CBC */ 230 .op = RTE_CRYPTO_OP_TYPE_SYMMETRIC, 231 .sym = { 232 .xform_type = RTE_CRYPTO_SYM_XFORM_CIPHER, 233 .cipher = { 234 .algo = RTE_CRYPTO_CIPHER_AES_CBC, 235 .block_size = 16, 236 .key_size = { 237 .min = 16, 238 .max = 32, 239 .increment = 8 240 }, 241 .iv_size = { 242 .min = 16, 243 .max = 16, 244 .increment = 0 245 } 246 } 247 } 248 } 249 } 250 251 252Capabilities Discovery 253~~~~~~~~~~~~~~~~~~~~~~ 254 255Discovering the features and capabilities of a Crypto device poll mode driver 256is achieved through the ``rte_cryptodev_info_get`` function. 257 258.. code-block:: c 259 260 void rte_cryptodev_info_get(uint8_t dev_id, 261 struct rte_cryptodev_info *dev_info); 262 263This allows the user to query a specific Crypto PMD and get all the device 264features and capabilities. The ``rte_cryptodev_info`` structure contains all the 265relevant information for the device. 266 267.. code-block:: c 268 269 struct rte_cryptodev_info { 270 const char *driver_name; 271 uint8_t driver_id; 272 struct rte_pci_device *pci_dev; 273 274 uint64_t feature_flags; 275 276 const struct rte_cryptodev_capabilities *capabilities; 277 278 unsigned max_nb_queue_pairs; 279 280 struct { 281 unsigned max_nb_sessions; 282 } sym; 283 }; 284 285 286Operation Processing 287-------------------- 288 289Scheduling of Crypto operations on DPDK's application data path is 290performed using a burst oriented asynchronous API set. A queue pair on a Crypto 291device accepts a burst of Crypto operations using enqueue burst API. On physical 292Crypto devices the enqueue burst API will place the operations to be processed 293on the devices hardware input queue, for virtual devices the processing of the 294Crypto operations is usually completed during the enqueue call to the Crypto 295device. The dequeue burst API will retrieve any processed operations available 296from the queue pair on the Crypto device, from physical devices this is usually 297directly from the devices processed queue, and for virtual device's from a 298``rte_ring`` where processed operations are place after being processed on the 299enqueue call. 300 301 302Private data 303~~~~~~~~~~~~ 304For session-based operations, the set and get API provides a mechanism for an 305application to store and retrieve the private data information stored along with 306the crypto session. 307 308For example, suppose an application is submitting a crypto operation with a session 309associated and wants to indicate private data information which is required to be 310used after completion of the crypto operation. In this case, the application can use 311the set API to set the private data and retrieve it using get API. 312 313.. code-block:: c 314 315 int rte_cryptodev_sym_session_set_private_data( 316 struct rte_cryptodev_sym_session *sess, void *data, uint16_t size); 317 318 void * rte_cryptodev_sym_session_get_private_data( 319 struct rte_cryptodev_sym_session *sess); 320 321 322For session-less mode, the private data information can be placed along with the 323``struct rte_crypto_op``. The ``rte_crypto_op::private_data_offset`` indicates the 324start of private data information. The offset is counted from the start of the 325rte_crypto_op including other crypto information such as the IVs (since there can 326be an IV also for authentication). 327 328 329Enqueue / Dequeue Burst APIs 330~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 331 332The burst enqueue API uses a Crypto device identifier and a queue pair 333identifier to specify the Crypto device queue pair to schedule the processing on. 334The ``nb_ops`` parameter is the number of operations to process which are 335supplied in the ``ops`` array of ``rte_crypto_op`` structures. 336The enqueue function returns the number of operations it actually enqueued for 337processing, a return value equal to ``nb_ops`` means that all packets have been 338enqueued. 339 340.. code-block:: c 341 342 uint16_t rte_cryptodev_enqueue_burst(uint8_t dev_id, uint16_t qp_id, 343 struct rte_crypto_op **ops, uint16_t nb_ops) 344 345The dequeue API uses the same format as the enqueue API of processed but 346the ``nb_ops`` and ``ops`` parameters are now used to specify the max processed 347operations the user wishes to retrieve and the location in which to store them. 348The API call returns the actual number of processed operations returned, this 349can never be larger than ``nb_ops``. 350 351.. code-block:: c 352 353 uint16_t rte_cryptodev_dequeue_burst(uint8_t dev_id, uint16_t qp_id, 354 struct rte_crypto_op **ops, uint16_t nb_ops) 355 356 357Operation Representation 358~~~~~~~~~~~~~~~~~~~~~~~~ 359 360An Crypto operation is represented by an rte_crypto_op structure, which is a 361generic metadata container for all necessary information required for the 362Crypto operation to be processed on a particular Crypto device poll mode driver. 363 364.. figure:: img/crypto_op.* 365 366The operation structure includes the operation type, the operation status 367and the session type (session-based/less), a reference to the operation 368specific data, which can vary in size and content depending on the operation 369being provisioned. It also contains the source mempool for the operation, 370if it allocated from a mempool. 371 372If Crypto operations are allocated from a Crypto operation mempool, see next 373section, there is also the ability to allocate private memory with the 374operation for applications purposes. 375 376Application software is responsible for specifying all the operation specific 377fields in the ``rte_crypto_op`` structure which are then used by the Crypto PMD 378to process the requested operation. 379 380 381Operation Management and Allocation 382~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 383 384The cryptodev library provides an API set for managing Crypto operations which 385utilize the Mempool Library to allocate operation buffers. Therefore, it ensures 386that the crytpo operation is interleaved optimally across the channels and 387ranks for optimal processing. 388A ``rte_crypto_op`` contains a field indicating the pool that it originated from. 389When calling ``rte_crypto_op_free(op)``, the operation returns to its original pool. 390 391.. code-block:: c 392 393 extern struct rte_mempool * 394 rte_crypto_op_pool_create(const char *name, enum rte_crypto_op_type type, 395 unsigned nb_elts, unsigned cache_size, uint16_t priv_size, 396 int socket_id); 397 398During pool creation ``rte_crypto_op_init()`` is called as a constructor to 399initialize each Crypto operation which subsequently calls 400``__rte_crypto_op_reset()`` to configure any operation type specific fields based 401on the type parameter. 402 403 404``rte_crypto_op_alloc()`` and ``rte_crypto_op_bulk_alloc()`` are used to allocate 405Crypto operations of a specific type from a given Crypto operation mempool. 406``__rte_crypto_op_reset()`` is called on each operation before being returned to 407allocate to a user so the operation is always in a good known state before use 408by the application. 409 410.. code-block:: c 411 412 struct rte_crypto_op *rte_crypto_op_alloc(struct rte_mempool *mempool, 413 enum rte_crypto_op_type type) 414 415 unsigned rte_crypto_op_bulk_alloc(struct rte_mempool *mempool, 416 enum rte_crypto_op_type type, 417 struct rte_crypto_op **ops, uint16_t nb_ops) 418 419``rte_crypto_op_free()`` is called by the application to return an operation to 420its allocating pool. 421 422.. code-block:: c 423 424 void rte_crypto_op_free(struct rte_crypto_op *op) 425 426 427Symmetric Cryptography Support 428------------------------------ 429 430The cryptodev library currently provides support for the following symmetric 431Crypto operations; cipher, authentication, including chaining of these 432operations, as well as also supporting AEAD operations. 433 434 435Session and Session Management 436~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 437 438Sessions are used in symmetric cryptographic processing to store the immutable 439data defined in a cryptographic transform which is used in the operation 440processing of a packet flow. Sessions are used to manage information such as 441expand cipher keys and HMAC IPADs and OPADs, which need to be calculated for a 442particular Crypto operation, but are immutable on a packet to packet basis for 443a flow. Crypto sessions cache this immutable data in a optimal way for the 444underlying PMD and this allows further acceleration of the offload of 445Crypto workloads. 446 447.. figure:: img/cryptodev_sym_sess.* 448 449The Crypto device framework provides APIs to allocate and initizalize sessions 450for crypto devices, where sessions are mempool objects. 451It is the application's responsibility to create and manage the session mempools. 452This approach allows for different scenarios such as having a single session 453mempool for all crypto devices (where the mempool object size is big 454enough to hold the private session of any crypto device), as well as having 455multiple session mempools of different sizes for better memory usage. 456 457An application can use ``rte_cryptodev_get_private_session_size()`` to 458get the private session size of given crypto device. This function would allow 459an application to calculate the max device session size of all crypto devices 460to create a single session mempool. 461If instead an application creates multiple session mempools, the Crypto device 462framework also provides ``rte_cryptodev_get_header_session_size`` to get 463the size of an uninitialized session. 464 465Once the session mempools have been created, ``rte_cryptodev_sym_session_create()`` 466is used to allocate an uninitialized session from the given mempool. 467The session then must be initialized using ``rte_cryptodev_sym_session_init()`` 468for each of the required crypto devices. A symmetric transform chain 469is used to specify the operation and its parameters. See the section below for 470details on transforms. 471 472When a session is no longer used, user must call ``rte_cryptodev_sym_session_clear()`` 473for each of the crypto devices that are using the session, to free all driver 474private session data. Once this is done, session should be freed using 475``rte_cryptodev_sym_session_free`` which returns them to their mempool. 476 477 478Transforms and Transform Chaining 479~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 480 481Symmetric Crypto transforms (``rte_crypto_sym_xform``) are the mechanism used 482to specify the details of the Crypto operation. For chaining of symmetric 483operations such as cipher encrypt and authentication generate, the next pointer 484allows transform to be chained together. Crypto devices which support chaining 485must publish the chaining of symmetric Crypto operations feature flag. 486 487Currently there are three transforms types cipher, authentication and AEAD. 488Also it is important to note that the order in which the 489transforms are passed indicates the order of the chaining. 490 491.. code-block:: c 492 493 struct rte_crypto_sym_xform { 494 struct rte_crypto_sym_xform *next; 495 /**< next xform in chain */ 496 enum rte_crypto_sym_xform_type type; 497 /**< xform type */ 498 union { 499 struct rte_crypto_auth_xform auth; 500 /**< Authentication / hash xform */ 501 struct rte_crypto_cipher_xform cipher; 502 /**< Cipher xform */ 503 struct rte_crypto_aead_xform aead; 504 /**< AEAD xform */ 505 }; 506 }; 507 508The API does not place a limit on the number of transforms that can be chained 509together but this will be limited by the underlying Crypto device poll mode 510driver which is processing the operation. 511 512.. figure:: img/crypto_xform_chain.* 513 514 515Symmetric Operations 516~~~~~~~~~~~~~~~~~~~~ 517 518The symmetric Crypto operation structure contains all the mutable data relating 519to performing symmetric cryptographic processing on a referenced mbuf data 520buffer. It is used for either cipher, authentication, AEAD and chained 521operations. 522 523As a minimum the symmetric operation must have a source data buffer (``m_src``), 524a valid session (or transform chain if in session-less mode) and the minimum 525authentication/ cipher/ AEAD parameters required depending on the type of operation 526specified in the session or the transform 527chain. 528 529.. code-block:: c 530 531 struct rte_crypto_sym_op { 532 struct rte_mbuf *m_src; 533 struct rte_mbuf *m_dst; 534 535 union { 536 struct rte_cryptodev_sym_session *session; 537 /**< Handle for the initialised session context */ 538 struct rte_crypto_sym_xform *xform; 539 /**< Session-less API Crypto operation parameters */ 540 }; 541 542 union { 543 struct { 544 struct { 545 uint32_t offset; 546 uint32_t length; 547 } data; /**< Data offsets and length for AEAD */ 548 549 struct { 550 uint8_t *data; 551 rte_iova_t phys_addr; 552 } digest; /**< Digest parameters */ 553 554 struct { 555 uint8_t *data; 556 rte_iova_t phys_addr; 557 } aad; 558 /**< Additional authentication parameters */ 559 } aead; 560 561 struct { 562 struct { 563 struct { 564 uint32_t offset; 565 uint32_t length; 566 } data; /**< Data offsets and length for ciphering */ 567 } cipher; 568 569 struct { 570 struct { 571 uint32_t offset; 572 uint32_t length; 573 } data; 574 /**< Data offsets and length for authentication */ 575 576 struct { 577 uint8_t *data; 578 rte_iova_t phys_addr; 579 } digest; /**< Digest parameters */ 580 } auth; 581 }; 582 }; 583 }; 584 585Sample code 586----------- 587 588There are various sample applications that show how to use the cryptodev library, 589such as the L2fwd with Crypto sample application (L2fwd-crypto) and 590the IPSec Security Gateway application (ipsec-secgw). 591 592While these applications demonstrate how an application can be created to perform 593generic crypto operation, the required complexity hides the basic steps of 594how to use the cryptodev APIs. 595 596The following sample code shows the basic steps to encrypt several buffers 597with AES-CBC (although performing other crypto operations is similar), 598using one of the crypto PMDs available in DPDK. 599 600.. code-block:: c 601 602 /* 603 * Simple example to encrypt several buffers with AES-CBC using 604 * the Cryptodev APIs. 605 */ 606 607 #define MAX_SESSIONS 1024 608 #define NUM_MBUFS 1024 609 #define POOL_CACHE_SIZE 128 610 #define BURST_SIZE 32 611 #define BUFFER_SIZE 1024 612 #define AES_CBC_IV_LENGTH 16 613 #define AES_CBC_KEY_LENGTH 16 614 #define IV_OFFSET (sizeof(struct rte_crypto_op) + \ 615 sizeof(struct rte_crypto_sym_op)) 616 617 struct rte_mempool *mbuf_pool, *crypto_op_pool, *session_pool; 618 unsigned int session_size; 619 int ret; 620 621 /* Initialize EAL. */ 622 ret = rte_eal_init(argc, argv); 623 if (ret < 0) 624 rte_exit(EXIT_FAILURE, "Invalid EAL arguments\n"); 625 626 uint8_t socket_id = rte_socket_id(); 627 628 /* Create the mbuf pool. */ 629 mbuf_pool = rte_pktmbuf_pool_create("mbuf_pool", 630 NUM_MBUFS, 631 POOL_CACHE_SIZE, 632 0, 633 RTE_MBUF_DEFAULT_BUF_SIZE, 634 socket_id); 635 if (mbuf_pool == NULL) 636 rte_exit(EXIT_FAILURE, "Cannot create mbuf pool\n"); 637 638 /* 639 * The IV is always placed after the crypto operation, 640 * so some private data is required to be reserved. 641 */ 642 unsigned int crypto_op_private_data = AES_CBC_IV_LENGTH; 643 644 /* Create crypto operation pool. */ 645 crypto_op_pool = rte_crypto_op_pool_create("crypto_op_pool", 646 RTE_CRYPTO_OP_TYPE_SYMMETRIC, 647 NUM_MBUFS, 648 POOL_CACHE_SIZE, 649 crypto_op_private_data, 650 socket_id); 651 if (crypto_op_pool == NULL) 652 rte_exit(EXIT_FAILURE, "Cannot create crypto op pool\n"); 653 654 /* Create the virtual crypto device. */ 655 char args[128]; 656 const char *crypto_name = "crypto_aesni_mb0"; 657 snprintf(args, sizeof(args), "socket_id=%d", socket_id); 658 ret = rte_vdev_init(crypto_name, args); 659 if (ret != 0) 660 rte_exit(EXIT_FAILURE, "Cannot create virtual device"); 661 662 uint8_t cdev_id = rte_cryptodev_get_dev_id(crypto_name); 663 664 /* Get private session data size. */ 665 session_size = rte_cryptodev_get_private_session_size(cdev_id); 666 667 /* 668 * Create session mempool, with two objects per session, 669 * one for the session header and another one for the 670 * private session data for the crypto device. 671 */ 672 session_pool = rte_mempool_create("session_pool", 673 MAX_SESSIONS * 2, 674 session_size, 675 POOL_CACHE_SIZE, 676 0, NULL, NULL, NULL, 677 NULL, socket_id, 678 0); 679 680 /* Configure the crypto device. */ 681 struct rte_cryptodev_config conf = { 682 .nb_queue_pairs = 1, 683 .socket_id = socket_id 684 }; 685 struct rte_cryptodev_qp_conf qp_conf = { 686 .nb_descriptors = 2048 687 }; 688 689 if (rte_cryptodev_configure(cdev_id, &conf) < 0) 690 rte_exit(EXIT_FAILURE, "Failed to configure cryptodev %u", cdev_id); 691 692 if (rte_cryptodev_queue_pair_setup(cdev_id, 0, &qp_conf, 693 socket_id, session_pool) < 0) 694 rte_exit(EXIT_FAILURE, "Failed to setup queue pair\n"); 695 696 if (rte_cryptodev_start(cdev_id) < 0) 697 rte_exit(EXIT_FAILURE, "Failed to start device\n"); 698 699 /* Create the crypto transform. */ 700 uint8_t cipher_key[16] = {0}; 701 struct rte_crypto_sym_xform cipher_xform = { 702 .next = NULL, 703 .type = RTE_CRYPTO_SYM_XFORM_CIPHER, 704 .cipher = { 705 .op = RTE_CRYPTO_CIPHER_OP_ENCRYPT, 706 .algo = RTE_CRYPTO_CIPHER_AES_CBC, 707 .key = { 708 .data = cipher_key, 709 .length = AES_CBC_KEY_LENGTH 710 }, 711 .iv = { 712 .offset = IV_OFFSET, 713 .length = AES_CBC_IV_LENGTH 714 } 715 } 716 }; 717 718 /* Create crypto session and initialize it for the crypto device. */ 719 struct rte_cryptodev_sym_session *session; 720 session = rte_cryptodev_sym_session_create(session_pool); 721 if (session == NULL) 722 rte_exit(EXIT_FAILURE, "Session could not be created\n"); 723 724 if (rte_cryptodev_sym_session_init(cdev_id, session, 725 &cipher_xform, session_pool) < 0) 726 rte_exit(EXIT_FAILURE, "Session could not be initialized " 727 "for the crypto device\n"); 728 729 /* Get a burst of crypto operations. */ 730 struct rte_crypto_op *crypto_ops[BURST_SIZE]; 731 if (rte_crypto_op_bulk_alloc(crypto_op_pool, 732 RTE_CRYPTO_OP_TYPE_SYMMETRIC, 733 crypto_ops, BURST_SIZE) == 0) 734 rte_exit(EXIT_FAILURE, "Not enough crypto operations available\n"); 735 736 /* Get a burst of mbufs. */ 737 struct rte_mbuf *mbufs[BURST_SIZE]; 738 if (rte_pktmbuf_alloc_bulk(mbuf_pool, mbufs, BURST_SIZE) < 0) 739 rte_exit(EXIT_FAILURE, "Not enough mbufs available"); 740 741 /* Initialize the mbufs and append them to the crypto operations. */ 742 unsigned int i; 743 for (i = 0; i < BURST_SIZE; i++) { 744 if (rte_pktmbuf_append(mbufs[i], BUFFER_SIZE) == NULL) 745 rte_exit(EXIT_FAILURE, "Not enough room in the mbuf\n"); 746 crypto_ops[i]->sym->m_src = mbufs[i]; 747 } 748 749 /* Set up the crypto operations. */ 750 for (i = 0; i < BURST_SIZE; i++) { 751 struct rte_crypto_op *op = crypto_ops[i]; 752 /* Modify bytes of the IV at the end of the crypto operation */ 753 uint8_t *iv_ptr = rte_crypto_op_ctod_offset(op, uint8_t *, 754 IV_OFFSET); 755 756 generate_random_bytes(iv_ptr, AES_CBC_IV_LENGTH); 757 758 op->sym->cipher.data.offset = 0; 759 op->sym->cipher.data.length = BUFFER_SIZE; 760 761 /* Attach the crypto session to the operation */ 762 rte_crypto_op_attach_sym_session(op, session); 763 } 764 765 /* Enqueue the crypto operations in the crypto device. */ 766 uint16_t num_enqueued_ops = rte_cryptodev_enqueue_burst(cdev_id, 0, 767 crypto_ops, BURST_SIZE); 768 769 /* 770 * Dequeue the crypto operations until all the operations 771 * are proccessed in the crypto device. 772 */ 773 uint16_t num_dequeued_ops, total_num_dequeued_ops = 0; 774 do { 775 struct rte_crypto_op *dequeued_ops[BURST_SIZE]; 776 num_dequeued_ops = rte_cryptodev_dequeue_burst(cdev_id, 0, 777 dequeued_ops, BURST_SIZE); 778 total_num_dequeued_ops += num_dequeued_ops; 779 780 /* Check if operation was processed successfully */ 781 for (i = 0; i < num_dequeued_ops; i++) { 782 if (dequeued_ops[i]->status != RTE_CRYPTO_OP_STATUS_SUCCESS) 783 rte_exit(EXIT_FAILURE, 784 "Some operations were not processed correctly"); 785 } 786 787 rte_mempool_put_bulk(crypto_op_pool, (void **)dequeued_ops, 788 num_dequeued_ops); 789 } while (total_num_dequeued_ops < num_enqueued_ops); 790 791 792Asymmetric Cryptography 793----------------------- 794 795Asymmetric functionality is currently not supported by the cryptodev API. 796 797 798Crypto Device API 799~~~~~~~~~~~~~~~~~ 800 801The cryptodev Library API is described in the *DPDK API Reference* document. 802