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 302Enqueue / Dequeue Burst APIs 303~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 304 305The burst enqueue API uses a Crypto device identifier and a queue pair 306identifier to specify the Crypto device queue pair to schedule the processing on. 307The ``nb_ops`` parameter is the number of operations to process which are 308supplied in the ``ops`` array of ``rte_crypto_op`` structures. 309The enqueue function returns the number of operations it actually enqueued for 310processing, a return value equal to ``nb_ops`` means that all packets have been 311enqueued. 312 313.. code-block:: c 314 315 uint16_t rte_cryptodev_enqueue_burst(uint8_t dev_id, uint16_t qp_id, 316 struct rte_crypto_op **ops, uint16_t nb_ops) 317 318The dequeue API uses the same format as the enqueue API of processed but 319the ``nb_ops`` and ``ops`` parameters are now used to specify the max processed 320operations the user wishes to retrieve and the location in which to store them. 321The API call returns the actual number of processed operations returned, this 322can never be larger than ``nb_ops``. 323 324.. code-block:: c 325 326 uint16_t rte_cryptodev_dequeue_burst(uint8_t dev_id, uint16_t qp_id, 327 struct rte_crypto_op **ops, uint16_t nb_ops) 328 329 330Operation Representation 331~~~~~~~~~~~~~~~~~~~~~~~~ 332 333An Crypto operation is represented by an rte_crypto_op structure, which is a 334generic metadata container for all necessary information required for the 335Crypto operation to be processed on a particular Crypto device poll mode driver. 336 337.. figure:: img/crypto_op.* 338 339The operation structure includes the operation type, the operation status 340and the session type (session-based/less), a reference to the operation 341specific data, which can vary in size and content depending on the operation 342being provisioned. It also contains the source mempool for the operation, 343if it allocated from a mempool. 344 345If Crypto operations are allocated from a Crypto operation mempool, see next 346section, there is also the ability to allocate private memory with the 347operation for applications purposes. 348 349Application software is responsible for specifying all the operation specific 350fields in the ``rte_crypto_op`` structure which are then used by the Crypto PMD 351to process the requested operation. 352 353 354Operation Management and Allocation 355~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 356 357The cryptodev library provides an API set for managing Crypto operations which 358utilize the Mempool Library to allocate operation buffers. Therefore, it ensures 359that the crytpo operation is interleaved optimally across the channels and 360ranks for optimal processing. 361A ``rte_crypto_op`` contains a field indicating the pool that it originated from. 362When calling ``rte_crypto_op_free(op)``, the operation returns to its original pool. 363 364.. code-block:: c 365 366 extern struct rte_mempool * 367 rte_crypto_op_pool_create(const char *name, enum rte_crypto_op_type type, 368 unsigned nb_elts, unsigned cache_size, uint16_t priv_size, 369 int socket_id); 370 371During pool creation ``rte_crypto_op_init()`` is called as a constructor to 372initialize each Crypto operation which subsequently calls 373``__rte_crypto_op_reset()`` to configure any operation type specific fields based 374on the type parameter. 375 376 377``rte_crypto_op_alloc()`` and ``rte_crypto_op_bulk_alloc()`` are used to allocate 378Crypto operations of a specific type from a given Crypto operation mempool. 379``__rte_crypto_op_reset()`` is called on each operation before being returned to 380allocate to a user so the operation is always in a good known state before use 381by the application. 382 383.. code-block:: c 384 385 struct rte_crypto_op *rte_crypto_op_alloc(struct rte_mempool *mempool, 386 enum rte_crypto_op_type type) 387 388 unsigned rte_crypto_op_bulk_alloc(struct rte_mempool *mempool, 389 enum rte_crypto_op_type type, 390 struct rte_crypto_op **ops, uint16_t nb_ops) 391 392``rte_crypto_op_free()`` is called by the application to return an operation to 393its allocating pool. 394 395.. code-block:: c 396 397 void rte_crypto_op_free(struct rte_crypto_op *op) 398 399 400Symmetric Cryptography Support 401------------------------------ 402 403The cryptodev library currently provides support for the following symmetric 404Crypto operations; cipher, authentication, including chaining of these 405operations, as well as also supporting AEAD operations. 406 407 408Session and Session Management 409~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 410 411Sessions are used in symmetric cryptographic processing to store the immutable 412data defined in a cryptographic transform which is used in the operation 413processing of a packet flow. Sessions are used to manage information such as 414expand cipher keys and HMAC IPADs and OPADs, which need to be calculated for a 415particular Crypto operation, but are immutable on a packet to packet basis for 416a flow. Crypto sessions cache this immutable data in a optimal way for the 417underlying PMD and this allows further acceleration of the offload of 418Crypto workloads. 419 420.. figure:: img/cryptodev_sym_sess.* 421 422The Crypto device framework provides APIs to allocate and initizalize sessions 423for crypto devices, where sessions are mempool objects. 424It is the application's responsibility to create and manage the session mempools. 425This approach allows for different scenarios such as having a single session 426mempool for all crypto devices (where the mempool object size is big 427enough to hold the private session of any crypto device), as well as having 428multiple session mempools of different sizes for better memory usage. 429 430An application can use ``rte_cryptodev_get_private_session_size()`` to 431get the private session size of given crypto device. This function would allow 432an application to calculate the max device session size of all crypto devices 433to create a single session mempool. 434If instead an application creates multiple session mempools, the Crypto device 435framework also provides ``rte_cryptodev_get_header_session_size`` to get 436the size of an uninitialized session. 437 438Once the session mempools have been created, ``rte_cryptodev_sym_session_create()`` 439is used to allocate an uninitialized session from the given mempool. 440The session then must be initialized using ``rte_cryptodev_sym_session_init()`` 441for each of the required crypto devices. A symmetric transform chain 442is used to specify the operation and its parameters. See the section below for 443details on transforms. 444 445When a session is no longer used, user must call ``rte_cryptodev_sym_session_clear()`` 446for each of the crypto devices that are using the session, to free all driver 447private session data. Once this is done, session should be freed using 448``rte_cryptodev_sym_session_free`` which returns them to their mempool. 449 450 451Transforms and Transform Chaining 452~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 453 454Symmetric Crypto transforms (``rte_crypto_sym_xform``) are the mechanism used 455to specify the details of the Crypto operation. For chaining of symmetric 456operations such as cipher encrypt and authentication generate, the next pointer 457allows transform to be chained together. Crypto devices which support chaining 458must publish the chaining of symmetric Crypto operations feature flag. 459 460Currently there are three transforms types cipher, authentication and AEAD. 461Also it is important to note that the order in which the 462transforms are passed indicates the order of the chaining. 463 464.. code-block:: c 465 466 struct rte_crypto_sym_xform { 467 struct rte_crypto_sym_xform *next; 468 /**< next xform in chain */ 469 enum rte_crypto_sym_xform_type type; 470 /**< xform type */ 471 union { 472 struct rte_crypto_auth_xform auth; 473 /**< Authentication / hash xform */ 474 struct rte_crypto_cipher_xform cipher; 475 /**< Cipher xform */ 476 struct rte_crypto_aead_xform aead; 477 /**< AEAD xform */ 478 }; 479 }; 480 481The API does not place a limit on the number of transforms that can be chained 482together but this will be limited by the underlying Crypto device poll mode 483driver which is processing the operation. 484 485.. figure:: img/crypto_xform_chain.* 486 487 488Symmetric Operations 489~~~~~~~~~~~~~~~~~~~~ 490 491The symmetric Crypto operation structure contains all the mutable data relating 492to performing symmetric cryptographic processing on a referenced mbuf data 493buffer. It is used for either cipher, authentication, AEAD and chained 494operations. 495 496As a minimum the symmetric operation must have a source data buffer (``m_src``), 497a valid session (or transform chain if in session-less mode) and the minimum 498authentication/ cipher/ AEAD parameters required depending on the type of operation 499specified in the session or the transform 500chain. 501 502.. code-block:: c 503 504 struct rte_crypto_sym_op { 505 struct rte_mbuf *m_src; 506 struct rte_mbuf *m_dst; 507 508 union { 509 struct rte_cryptodev_sym_session *session; 510 /**< Handle for the initialised session context */ 511 struct rte_crypto_sym_xform *xform; 512 /**< Session-less API Crypto operation parameters */ 513 }; 514 515 union { 516 struct { 517 struct { 518 uint32_t offset; 519 uint32_t length; 520 } data; /**< Data offsets and length for AEAD */ 521 522 struct { 523 uint8_t *data; 524 rte_iova_t phys_addr; 525 } digest; /**< Digest parameters */ 526 527 struct { 528 uint8_t *data; 529 rte_iova_t phys_addr; 530 } aad; 531 /**< Additional authentication parameters */ 532 } aead; 533 534 struct { 535 struct { 536 struct { 537 uint32_t offset; 538 uint32_t length; 539 } data; /**< Data offsets and length for ciphering */ 540 } cipher; 541 542 struct { 543 struct { 544 uint32_t offset; 545 uint32_t length; 546 } data; 547 /**< Data offsets and length for authentication */ 548 549 struct { 550 uint8_t *data; 551 rte_iova_t phys_addr; 552 } digest; /**< Digest parameters */ 553 } auth; 554 }; 555 }; 556 }; 557 558Sample code 559----------- 560 561There are various sample applications that show how to use the cryptodev library, 562such as the L2fwd with Crypto sample application (L2fwd-crypto) and 563the IPSec Security Gateway application (ipsec-secgw). 564 565While these applications demonstrate how an application can be created to perform 566generic crypto operation, the required complexity hides the basic steps of 567how to use the cryptodev APIs. 568 569The following sample code shows the basic steps to encrypt several buffers 570with AES-CBC (although performing other crypto operations is similar), 571using one of the crypto PMDs available in DPDK. 572 573.. code-block:: c 574 575 /* 576 * Simple example to encrypt several buffers with AES-CBC using 577 * the Cryptodev APIs. 578 */ 579 580 #define MAX_SESSIONS 1024 581 #define NUM_MBUFS 1024 582 #define POOL_CACHE_SIZE 128 583 #define BURST_SIZE 32 584 #define BUFFER_SIZE 1024 585 #define AES_CBC_IV_LENGTH 16 586 #define AES_CBC_KEY_LENGTH 16 587 #define IV_OFFSET (sizeof(struct rte_crypto_op) + \ 588 sizeof(struct rte_crypto_sym_op)) 589 590 struct rte_mempool *mbuf_pool, *crypto_op_pool, *session_pool; 591 unsigned int session_size; 592 int ret; 593 594 /* Initialize EAL. */ 595 ret = rte_eal_init(argc, argv); 596 if (ret < 0) 597 rte_exit(EXIT_FAILURE, "Invalid EAL arguments\n"); 598 599 uint8_t socket_id = rte_socket_id(); 600 601 /* Create the mbuf pool. */ 602 mbuf_pool = rte_pktmbuf_pool_create("mbuf_pool", 603 NUM_MBUFS, 604 POOL_CACHE_SIZE, 605 0, 606 RTE_MBUF_DEFAULT_BUF_SIZE, 607 socket_id); 608 if (mbuf_pool == NULL) 609 rte_exit(EXIT_FAILURE, "Cannot create mbuf pool\n"); 610 611 /* 612 * The IV is always placed after the crypto operation, 613 * so some private data is required to be reserved. 614 */ 615 unsigned int crypto_op_private_data = AES_CBC_IV_LENGTH; 616 617 /* Create crypto operation pool. */ 618 crypto_op_pool = rte_crypto_op_pool_create("crypto_op_pool", 619 RTE_CRYPTO_OP_TYPE_SYMMETRIC, 620 NUM_MBUFS, 621 POOL_CACHE_SIZE, 622 crypto_op_private_data, 623 socket_id); 624 if (crypto_op_pool == NULL) 625 rte_exit(EXIT_FAILURE, "Cannot create crypto op pool\n"); 626 627 /* Create the virtual crypto device. */ 628 char args[128]; 629 const char *crypto_name = "crypto_aesni_mb0"; 630 snprintf(args, sizeof(args), "socket_id=%d", socket_id); 631 ret = rte_vdev_init(crypto_name, args); 632 if (ret != 0) 633 rte_exit(EXIT_FAILURE, "Cannot create virtual device"); 634 635 uint8_t cdev_id = rte_cryptodev_get_dev_id(crypto_name); 636 637 /* Get private session data size. */ 638 session_size = rte_cryptodev_get_private_session_size(cdev_id); 639 640 /* 641 * Create session mempool, with two objects per session, 642 * one for the session header and another one for the 643 * private session data for the crypto device. 644 */ 645 session_pool = rte_mempool_create("session_pool", 646 MAX_SESSIONS * 2, 647 session_size, 648 POOL_CACHE_SIZE, 649 0, NULL, NULL, NULL, 650 NULL, socket_id, 651 0); 652 653 /* Configure the crypto device. */ 654 struct rte_cryptodev_config conf = { 655 .nb_queue_pairs = 1, 656 .socket_id = socket_id 657 }; 658 struct rte_cryptodev_qp_conf qp_conf = { 659 .nb_descriptors = 2048 660 }; 661 662 if (rte_cryptodev_configure(cdev_id, &conf) < 0) 663 rte_exit(EXIT_FAILURE, "Failed to configure cryptodev %u", cdev_id); 664 665 if (rte_cryptodev_queue_pair_setup(cdev_id, 0, &qp_conf, 666 socket_id, session_pool) < 0) 667 rte_exit(EXIT_FAILURE, "Failed to setup queue pair\n"); 668 669 if (rte_cryptodev_start(cdev_id) < 0) 670 rte_exit(EXIT_FAILURE, "Failed to start device\n"); 671 672 /* Create the crypto transform. */ 673 uint8_t cipher_key[16] = {0}; 674 struct rte_crypto_sym_xform cipher_xform = { 675 .next = NULL, 676 .type = RTE_CRYPTO_SYM_XFORM_CIPHER, 677 .cipher = { 678 .op = RTE_CRYPTO_CIPHER_OP_ENCRYPT, 679 .algo = RTE_CRYPTO_CIPHER_AES_CBC, 680 .key = { 681 .data = cipher_key, 682 .length = AES_CBC_KEY_LENGTH 683 }, 684 .iv = { 685 .offset = IV_OFFSET, 686 .length = AES_CBC_IV_LENGTH 687 } 688 } 689 }; 690 691 /* Create crypto session and initialize it for the crypto device. */ 692 struct rte_cryptodev_sym_session *session; 693 session = rte_cryptodev_sym_session_create(session_pool); 694 if (session == NULL) 695 rte_exit(EXIT_FAILURE, "Session could not be created\n"); 696 697 if (rte_cryptodev_sym_session_init(cdev_id, session, 698 &cipher_xform, session_pool) < 0) 699 rte_exit(EXIT_FAILURE, "Session could not be initialized " 700 "for the crypto device\n"); 701 702 /* Get a burst of crypto operations. */ 703 struct rte_crypto_op *crypto_ops[BURST_SIZE]; 704 if (rte_crypto_op_bulk_alloc(crypto_op_pool, 705 RTE_CRYPTO_OP_TYPE_SYMMETRIC, 706 crypto_ops, BURST_SIZE) == 0) 707 rte_exit(EXIT_FAILURE, "Not enough crypto operations available\n"); 708 709 /* Get a burst of mbufs. */ 710 struct rte_mbuf *mbufs[BURST_SIZE]; 711 if (rte_pktmbuf_alloc_bulk(mbuf_pool, mbufs, BURST_SIZE) < 0) 712 rte_exit(EXIT_FAILURE, "Not enough mbufs available"); 713 714 /* Initialize the mbufs and append them to the crypto operations. */ 715 unsigned int i; 716 for (i = 0; i < BURST_SIZE; i++) { 717 if (rte_pktmbuf_append(mbufs[i], BUFFER_SIZE) == NULL) 718 rte_exit(EXIT_FAILURE, "Not enough room in the mbuf\n"); 719 crypto_ops[i]->sym->m_src = mbufs[i]; 720 } 721 722 /* Set up the crypto operations. */ 723 for (i = 0; i < BURST_SIZE; i++) { 724 struct rte_crypto_op *op = crypto_ops[i]; 725 /* Modify bytes of the IV at the end of the crypto operation */ 726 uint8_t *iv_ptr = rte_crypto_op_ctod_offset(op, uint8_t *, 727 IV_OFFSET); 728 729 generate_random_bytes(iv_ptr, AES_CBC_IV_LENGTH); 730 731 op->sym->cipher.data.offset = 0; 732 op->sym->cipher.data.length = BUFFER_SIZE; 733 734 /* Attach the crypto session to the operation */ 735 rte_crypto_op_attach_sym_session(op, session); 736 } 737 738 /* Enqueue the crypto operations in the crypto device. */ 739 uint16_t num_enqueued_ops = rte_cryptodev_enqueue_burst(cdev_id, 0, 740 crypto_ops, BURST_SIZE); 741 742 /* 743 * Dequeue the crypto operations until all the operations 744 * are proccessed in the crypto device. 745 */ 746 uint16_t num_dequeued_ops, total_num_dequeued_ops = 0; 747 do { 748 struct rte_crypto_op *dequeued_ops[BURST_SIZE]; 749 num_dequeued_ops = rte_cryptodev_dequeue_burst(cdev_id, 0, 750 dequeued_ops, BURST_SIZE); 751 total_num_dequeued_ops += num_dequeued_ops; 752 753 /* Check if operation was processed successfully */ 754 for (i = 0; i < num_dequeued_ops; i++) { 755 if (dequeued_ops[i]->status != RTE_CRYPTO_OP_STATUS_SUCCESS) 756 rte_exit(EXIT_FAILURE, 757 "Some operations were not processed correctly"); 758 } 759 760 rte_mempool_put_bulk(crypto_op_pool, (void **)dequeued_ops, 761 num_dequeued_ops); 762 } while (total_num_dequeued_ops < num_enqueued_ops); 763 764 765Asymmetric Cryptography 766----------------------- 767 768Asymmetric functionality is currently not supported by the cryptodev API. 769 770 771Crypto Device API 772~~~~~~~~~~~~~~~~~ 773 774The cryptodev Library API is described in the *DPDK API Reference* document. 775