doc/guides/cryptodevs/qat.rst

   1 ..  SPDX-License-Identifier: BSD-3-Clause
   2     Copyright(c) 2015-2016 Intel Corporation.
   3
   4 Intel(R) QuickAssist (QAT) Crypto Poll Mode Driver
   5 ==================================================
   6
   7 QAT documentation consists of three parts:
   8
   9 * Details of the symmetric crypto service below.
  10 * Details of the `compression service <http://dpdk.org/doc/guides/compressdevs/qat_comp.html>`_
  11   in the compressdev drivers section.
  12 * Details of building the common QAT infrastructure and the PMDs to support the
  13   above services. See :ref:`building_qat` below.
  14
  15
  16 Symmetric Crypto Service on QAT
  17 -------------------------------
  18
  19 The QAT crypto PMD provides poll mode crypto driver support for the following
  20 hardware accelerator devices:
  21
  22 * ``Intel QuickAssist Technology DH895xCC``
  23 * ``Intel QuickAssist Technology C62x``
  24 * ``Intel QuickAssist Technology C3xxx``
  25 * ``Intel QuickAssist Technology D15xx``
  26 * ``Intel QuickAssist Technology C4xxx``
  27
  28
  29 Features
  30 ~~~~~~~~
  31
  32 The QAT PMD has support for:
  33
  34 Cipher algorithms:
  35
  36 * ``RTE_CRYPTO_CIPHER_3DES_CBC``
  37 * ``RTE_CRYPTO_CIPHER_3DES_CTR``
  38 * ``RTE_CRYPTO_CIPHER_AES128_CBC``
  39 * ``RTE_CRYPTO_CIPHER_AES192_CBC``
  40 * ``RTE_CRYPTO_CIPHER_AES256_CBC``
  41 * ``RTE_CRYPTO_CIPHER_AES128_CTR``
  42 * ``RTE_CRYPTO_CIPHER_AES192_CTR``
  43 * ``RTE_CRYPTO_CIPHER_AES256_CTR``
  44 * ``RTE_CRYPTO_CIPHER_SNOW3G_UEA2``
  45 * ``RTE_CRYPTO_CIPHER_NULL``
  46 * ``RTE_CRYPTO_CIPHER_KASUMI_F8``
  47 * ``RTE_CRYPTO_CIPHER_DES_CBC``
  48 * ``RTE_CRYPTO_CIPHER_AES_DOCSISBPI``
  49 * ``RTE_CRYPTO_CIPHER_DES_DOCSISBPI``
  50 * ``RTE_CRYPTO_CIPHER_ZUC_EEA3``
  51
  52 Hash algorithms:
  53
  54 * ``RTE_CRYPTO_AUTH_SHA1_HMAC``
  55 * ``RTE_CRYPTO_AUTH_SHA224_HMAC``
  56 * ``RTE_CRYPTO_AUTH_SHA256_HMAC``
  57 * ``RTE_CRYPTO_AUTH_SHA384_HMAC``
  58 * ``RTE_CRYPTO_AUTH_SHA512_HMAC``
  59 * ``RTE_CRYPTO_AUTH_AES_XCBC_MAC``
  60 * ``RTE_CRYPTO_AUTH_SNOW3G_UIA2``
  61 * ``RTE_CRYPTO_AUTH_MD5_HMAC``
  62 * ``RTE_CRYPTO_AUTH_NULL``
  63 * ``RTE_CRYPTO_AUTH_KASUMI_F9``
  64 * ``RTE_CRYPTO_AUTH_AES_GMAC``
  65 * ``RTE_CRYPTO_AUTH_ZUC_EIA3``
  66 * ``RTE_CRYPTO_AUTH_AES_CMAC``
  67
  68 Supported AEAD algorithms:
  69
  70 * ``RTE_CRYPTO_AEAD_AES_GCM``
  71 * ``RTE_CRYPTO_AEAD_AES_CCM``
  72
  73
  74 Limitations
  75 ~~~~~~~~~~~
  76
  77 * Only supports the session-oriented API implementation (session-less APIs are not supported).
  78 * SNOW 3G (UEA2), KASUMI (F8) and ZUC (EEA3) supported only if cipher length and offset fields are byte-multiple.
  79 * SNOW 3G (UIA2) and ZUC (EIA3) supported only if hash length and offset fields are byte-multiple.
  80 * No BSD support as BSD QAT kernel driver not available.
  81 * ZUC EEA3/EIA3 is not supported by dh895xcc devices
  82 * Maximum additional authenticated data (AAD) for GCM is 240 bytes long.
  83 * Queue pairs are not thread-safe (that is, within a single queue pair, RX and TX from different lcores is not supported).
  84
  85
  86 Extra notes on KASUMI F9
  87 ~~~~~~~~~~~~~~~~~~~~~~~~
  88
  89 When using KASUMI F9 authentication algorithm, the input buffer must be
  90 constructed according to the
  91 `3GPP KASUMI specification <http://cryptome.org/3gpp/35201-900.pdf>`_
  92 (section 4.4, page 13). The input buffer has to have COUNT (4 bytes),
  93 FRESH (4 bytes), MESSAGE and DIRECTION (1 bit) concatenated. After the DIRECTION
  94 bit, a single '1' bit is appended, followed by between 0 and 7 '0' bits, so that
  95 the total length of the buffer is multiple of 8 bits. Note that the actual
  96 message can be any length, specified in bits.
  97
  98 Once this buffer is passed this way, when creating the crypto operation,
  99 length of data to authenticate "op.sym.auth.data.length" must be the length
 100 of all the items described above, including the padding at the end.
 101 Also, offset of data to authenticate "op.sym.auth.data.offset"
 102 must be such that points at the start of the COUNT bytes.
 103
 104
 105
 106 .. _building_qat:
 107
 108 Building PMDs on QAT
 109 --------------------
 110
 111 A QAT device can host multiple acceleration services:
 112
 113 * symmetric cryptography
 114 * data compression
 115
 116 These services are provided to DPDK applications via PMDs which register to
 117 implement the corresponding cryptodev and compressdev APIs. The PMDs use
 118 common QAT driver code which manages the QAT PCI device. They also depend on a
 119 QAT kernel driver being installed on the platform, see :ref:`qat_kernel` below.
 120
 121
 122 Configuring and Building the DPDK QAT PMDs
 123 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 124
 125
 126 Further information on configuring, building and installing DPDK is described
 127 `here <http://dpdk.org/doc/guides/linux_gsg/build_dpdk.html>`_.
 128
 129
 130 Quick instructions for QAT cryptodev PMD are as follows:
 131
 132 .. code-block:: console
 133
 134         cd to the top-level DPDK directory
 135         make defconfig
 136         sed -i 's,\(CONFIG_RTE_LIBRTE_PMD_QAT_SYM\)=n,\1=y,' build/.config
 137         make
 138
 139 Quick instructions for QAT compressdev PMD are as follows:
 140
 141 .. code-block:: console
 142
 143         cd to the top-level DPDK directory
 144         make defconfig
 145         make
 146
 147
 148 Build Configuration
 149 ~~~~~~~~~~~~~~~~~~~
 150
 151 These are the build configuration options affecting QAT, and their default values:
 152
 153 .. code-block:: console
 154
 155         CONFIG_RTE_LIBRTE_PMD_QAT=y
 156         CONFIG_RTE_LIBRTE_PMD_QAT_SYM=n
 157         CONFIG_RTE_PMD_QAT_MAX_PCI_DEVICES=48
 158         CONFIG_RTE_PMD_QAT_COMP_SGL_MAX_SEGMENTS=16
 159
 160 CONFIG_RTE_LIBRTE_PMD_QAT must be enabled for any QAT PMD to be built.
 161
 162 The QAT cryptodev PMD has an external dependency on libcrypto, so is not
 163 built by default. CONFIG_RTE_LIBRTE_PMD_QAT_SYM should be enabled to build it.
 164
 165 The QAT compressdev PMD has no external dependencies, so needs no configuration
 166 options and is built by default.
 167
 168 The number of VFs per PF varies - see table below. If multiple QAT packages are
 169 installed on a platform then CONFIG_RTE_PMD_QAT_MAX_PCI_DEVICES should be
 170 adjusted to the number of VFs which the QAT common code will need to handle.
 171 Note, there is a separate config item for max cryptodevs CONFIG_RTE_CRYPTO_MAX_DEVS,
 172 if necessary this should be adjusted to handle the total of QAT and other devices
 173 which the process will use.
 174
 175 QAT allocates internal structures to handle SGLs. For the compression service
 176 CONFIG_RTE_PMD_QAT_COMP_SGL_MAX_SEGMENTS can be changed if more segments are needed.
 177 An extra (max_inflight_ops x 16) bytes per queue_pair will be used for every increment.
 178
 179
 180 Device and driver naming
 181 ~~~~~~~~~~~~~~~~~~~~~~~~
 182
 183 * The qat cryptodev driver name is "crypto_qat".
 184   The "rte_cryptodev_devices_get()" returns the devices exposed by this driver.
 185
 186 * Each qat crypto device has a unique name, in format
 187   "<pci bdf>_<service>", e.g. "0000:41:01.0_qat_sym".
 188   This name can be passed to "rte_cryptodev_get_dev_id()" to get the device_id.
 189
 190 .. Note::
 191
 192         The qat crypto driver name is passed to the dpdk-test-crypto-perf tool in the "-devtype" parameter.
 193
 194         The qat crypto device name is in the format of the slave parameter passed to the crypto scheduler.
 195
 196 * The qat compressdev driver name is "compress_qat".
 197   The rte_compressdev_devices_get() returns the devices exposed by this driver.
 198
 199 * Each qat compression device has a unique name, in format
 200   <pci bdf>_<service>, e.g. "0000:41:01.0_qat_comp".
 201   This name can be passed to rte_compressdev_get_dev_id() to get the device_id.
 202
 203 .. _qat_kernel:
 204
 205 Dependency on the QAT kernel driver
 206 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 207
 208 To use QAT an SRIOV-enabled QAT kernel driver is required. The VF
 209 devices created and initialised by this driver will be used by the QAT PMDs.
 210
 211 Instructions for installation are below, but first an explanation of the
 212 relationships between the PF/VF devices and the PMDs visible to
 213 DPDK applications.
 214
 215 Each QuickAssist PF device exposes a number of VF devices. Each VF device can
 216 enable one cryptodev PMD and/or one compressdev PMD.
 217 These QAT PMDs share the same underlying device and pci-mgmt code, but are
 218 enumerated independently on their respective APIs and appear as independent
 219 devices to applications.
 220
 221 .. Note::
 222
 223    Each VF can only be used by one DPDK process. It is not possible to share
 224    the same VF across multiple processes, even if these processes are using
 225    different acceleration services.
 226
 227    Conversely one DPDK process can use one or more QAT VFs and can expose both
 228    cryptodev and compressdev instances on each of those VFs.
 229
 230
 231 Available kernel drivers
 232 ~~~~~~~~~~~~~~~~~~~~~~~~
 233
 234 Kernel drivers for each device are listed in the following table. Scroll right
 235 to check that the driver and device supports the service you require.
 236
 237
 238 .. _table_qat_pmds_drivers:
 239
 240 .. table:: QAT device generations, devices and drivers
 241
 242    +-----+----------+---------------+---------------+------------+--------+------+--------+--------+-----------+-------------+
 243    | Gen | Device   | Driver/ver    | Kernel Module | Pci Driver | PF Did | #PFs | VF Did | VFs/PF | cryptodev | compressdev |
 244    +=====+==========+===============+===============+============+========+======+========+========+===========+=============+
 245    | 1   | DH895xCC | linux/4.4+    | qat_dh895xcc  | dh895xcc   | 435    | 1    | 443    | 32     | Yes       | No          |
 246    +-----+----------+---------------+---------------+------------+--------+------+--------+--------+-----------+-------------+
 247    | "   | "        | 01.org/4.2.0+ | "             | "          | "      | "    | "      | "      | Yes       | No          |
 248    +-----+----------+---------------+---------------+------------+--------+------+--------+--------+-----------+-------------+
 249    | 2   | C62x     | linux/4.5+    | qat_c62x      | c6xx       | 37c8   | 3    | 37c9   | 16     | Yes       | No          |
 250    +-----+----------+---------------+---------------+------------+--------+------+--------+--------+-----------+-------------+
 251    | "   | "        | 01.org/4.2.0+ | "             | "          | "      | "    | "      | "      | Yes       | Yes         |
 252    +-----+----------+---------------+---------------+------------+--------+------+--------+--------+-----------+-------------+
 253    | 2   | C3xxx    | linux/4.5+    | qat_c3xxx     | c3xxx      | 19e2   | 1    | 19e3   | 16     | Yes       | No          |
 254    +-----+----------+---------------+---------------+------------+--------+------+--------+--------+-----------+-------------+
 255    | "   | "        | 01.org/4.2.0+ | "             | "          | "      | "    | "      | "      | Yes       | Yes         |
 256    +-----+----------+---------------+---------------+------------+--------+------+--------+--------+-----------+-------------+
 257    | 2   | D15xx    | p             | qat_d15xx     | d15xx      | 6f54   | 1    | 6f55   | 16     | Yes       | No          |
 258    +-----+----------+---------------+---------------+------------+--------+------+--------+--------+-----------+-------------+
 259    | 3   | C4xxx    | p             | qat_c4xxx     | c4xxx      | 18a0   | 1    | 18a1   | 128    | Yes       | No          |
 260    +-----+----------+---------------+---------------+------------+--------+------+--------+--------+-----------+-------------+
 261
 262
 263 The ``Driver`` column indicates either the Linux kernel version in which
 264 support for this device was introduced or a driver available on Intel's 01.org
 265 website. There are both linux and 01.org kernel drivers available for some
 266 devices. p = release pending.
 267
 268 If you are running on a kernel which includes a driver for your device, see
 269 `Installation using kernel.org driver`_ below. Otherwise see
 270 `Installation using 01.org QAT driver`_.
 271
 272
 273 Installation using kernel.org driver
 274 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 275
 276 The examples below are based on the C62x device, if you have a different device
 277 use the corresponding values in the above table.
 278
 279 In BIOS ensure that SRIOV is enabled and either:
 280
 281 * Disable VT-d or
 282 * Enable VT-d and set ``"intel_iommu=on iommu=pt"`` in the grub file.
 283
 284 Check that the QAT driver is loaded on your system, by executing::
 285
 286     lsmod | grep qa
 287
 288 You should see the kernel module for your device listed, e.g.::
 289
 290     qat_c62x               5626  0
 291     intel_qat              82336  1 qat_c62x
 292
 293 Next, you need to expose the Virtual Functions (VFs) using the sysfs file system.
 294
 295 First find the BDFs (Bus-Device-Function) of the physical functions (PFs) of
 296 your device, e.g.::
 297
 298     lspci -d:37c8
 299
 300 You should see output similar to::
 301
 302     1a:00.0 Co-processor: Intel Corporation Device 37c8
 303     3d:00.0 Co-processor: Intel Corporation Device 37c8
 304     3f:00.0 Co-processor: Intel Corporation Device 37c8
 305
 306 Enable the VFs for each PF by echoing the number of VFs per PF to the pci driver::
 307
 308      echo 16 > /sys/bus/pci/drivers/c6xx/0000:1a:00.0/sriov_numvfs
 309      echo 16 > /sys/bus/pci/drivers/c6xx/0000:3d:00.0/sriov_numvfs
 310      echo 16 > /sys/bus/pci/drivers/c6xx/0000:3f:00.0/sriov_numvfs
 311
 312 Check that the VFs are available for use. For example ``lspci -d:37c9`` should
 313 list 48 VF devices available for a ``C62x`` device.
 314
 315 To complete the installation follow the instructions in
 316 `Binding the available VFs to the DPDK UIO driver`_.
 317
 318 .. Note::
 319
 320    If the QAT kernel modules are not loaded and you see an error like ``Failed
 321    to load MMP firmware qat_895xcc_mmp.bin`` in kernel logs, this may be as a
 322    result of not using a distribution, but just updating the kernel directly.
 323
 324    Download firmware from the `kernel firmware repo
 325    <http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/>`_.
 326
 327    Copy qat binaries to ``/lib/firmware``::
 328
 329       cp qat_895xcc.bin /lib/firmware
 330       cp qat_895xcc_mmp.bin /lib/firmware
 331
 332    Change to your linux source root directory and start the qat kernel modules::
 333
 334       insmod ./drivers/crypto/qat/qat_common/intel_qat.ko
 335       insmod ./drivers/crypto/qat/qat_dh895xcc/qat_dh895xcc.ko
 336
 337
 338 .. Note::
 339
 340    If you see the following warning in ``/var/log/messages`` it can be ignored:
 341    ``IOMMU should be enabled for SR-IOV to work correctly``.
 342
 343
 344 Installation using 01.org QAT driver
 345 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 346
 347 Download the latest QuickAssist Technology Driver from `01.org
 348 <https://01.org/packet-processing/intel%C2%AE-quickassist-technology-drivers-and-patches>`_.
 349 Consult the *Getting Started Guide* at the same URL for further information.
 350
 351 The steps below assume you are:
 352
 353 * Building on a platform with one ``C62x`` device.
 354 * Using package ``qat1.7.l.4.2.0-000xx.tar.gz``.
 355 * On Fedora26 kernel ``4.11.11-300.fc26.x86_64``.
 356
 357 In the BIOS ensure that SRIOV is enabled and VT-d is disabled.
 358
 359 Uninstall any existing QAT driver, for example by running:
 360
 361 * ``./installer.sh uninstall`` in the directory where originally installed.
 362
 363
 364 Build and install the SRIOV-enabled QAT driver::
 365
 366     mkdir /QAT
 367     cd /QAT
 368
 369     # Copy the package to this location and unpack
 370     tar zxof qat1.7.l.4.2.0-000xx.tar.gz
 371
 372     ./configure --enable-icp-sriov=host
 373     make install
 374
 375 You can use ``cat /sys/kernel/debug/qat<your device type and bdf>/version/fw`` to confirm the driver is correctly installed and is using firmware version 4.2.0.
 376 You can use ``lspci -d:37c9`` to confirm the presence of the 16 VF devices available per ``C62x`` PF.
 377
 378 Confirm the driver is correctly installed and is using firmware version 4.2.0::
 379
 380     cat /sys/kernel/debug/qat<your device type and bdf>/version/fw
 381
 382
 383 Confirm the presence of 48 VF devices - 16 per PF::
 384
 385     lspci -d:37c9
 386
 387
 388 To complete the installation - follow instructions in `Binding the available VFs to the DPDK UIO driver`_.
 389
 390 .. Note::
 391
 392    If using a later kernel and the build fails with an error relating to
 393    ``strict_stroul`` not being available apply the following patch:
 394
 395    .. code-block:: diff
 396
 397       /QAT/QAT1.6/quickassist/utilities/downloader/Target_CoreLibs/uclo/include/linux/uclo_platform.h
 398       + #if LINUX_VERSION_CODE >= KERNEL_VERSION(3,18,5)
 399       + #define STR_TO_64(str, base, num, endPtr) {endPtr=NULL; if (kstrtoul((str), (base), (num))) printk("Error strtoull convert %s\n", str); }
 400       + #else
 401       #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,38)
 402       #define STR_TO_64(str, base, num, endPtr) {endPtr=NULL; if (strict_strtoull((str), (base), (num))) printk("Error strtoull convert %s\n", str); }
 403       #else
 404       #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,25)
 405       #define STR_TO_64(str, base, num, endPtr) {endPtr=NULL; strict_strtoll((str), (base), (num));}
 406       #else
 407       #define STR_TO_64(str, base, num, endPtr)                                 \
 408            do {                                                               \
 409                  if (str[0] == '-')                                           \
 410                  {                                                            \
 411                       *(num) = -(simple_strtoull((str+1), &(endPtr), (base))); \
 412                  }else {                                                      \
 413                       *(num) = simple_strtoull((str), &(endPtr), (base));      \
 414                  }                                                            \
 415            } while(0)
 416       + #endif
 417       #endif
 418       #endif
 419
 420
 421 .. Note::
 422
 423    If the build fails due to missing header files you may need to do following::
 424
 425       sudo yum install zlib-devel
 426       sudo yum install openssl-devel
 427       sudo yum install libudev-devel
 428
 429 .. Note::
 430
 431    If the build or install fails due to mismatching kernel sources you may need to do the following::
 432
 433       sudo yum install kernel-headers-`uname -r`
 434       sudo yum install kernel-src-`uname -r`
 435       sudo yum install kernel-devel-`uname -r`
 436
 437
 438 Binding the available VFs to the DPDK UIO driver
 439 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 440
 441 Unbind the VFs from the stock driver so they can be bound to the uio driver.
 442
 443 For an Intel(R) QuickAssist Technology DH895xCC device
 444 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 445
 446 The unbind command below assumes ``BDFs`` of ``03:01.00-03:04.07``, if your
 447 VFs are different adjust the unbind command below::
 448
 449     for device in $(seq 1 4); do \
 450         for fn in $(seq 0 7); do \
 451             echo -n 0000:03:0${device}.${fn} > \
 452             /sys/bus/pci/devices/0000\:03\:0${device}.${fn}/driver/unbind; \
 453         done; \
 454     done
 455
 456 For an Intel(R) QuickAssist Technology C62x device
 457 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 458
 459 The unbind command below assumes ``BDFs`` of ``1a:01.00-1a:02.07``,
 460 ``3d:01.00-3d:02.07`` and ``3f:01.00-3f:02.07``, if your VFs are different
 461 adjust the unbind command below::
 462
 463     for device in $(seq 1 2); do \
 464         for fn in $(seq 0 7); do \
 465             echo -n 0000:1a:0${device}.${fn} > \
 466             /sys/bus/pci/devices/0000\:1a\:0${device}.${fn}/driver/unbind; \
 467
 468             echo -n 0000:3d:0${device}.${fn} > \
 469             /sys/bus/pci/devices/0000\:3d\:0${device}.${fn}/driver/unbind; \
 470
 471             echo -n 0000:3f:0${device}.${fn} > \
 472             /sys/bus/pci/devices/0000\:3f\:0${device}.${fn}/driver/unbind; \
 473         done; \
 474     done
 475
 476 For Intel(R) QuickAssist Technology C3xxx or D15xx device
 477 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 478
 479 The unbind command below assumes ``BDFs`` of ``01:01.00-01:02.07``, if your
 480 VFs are different adjust the unbind command below::
 481
 482     for device in $(seq 1 2); do \
 483         for fn in $(seq 0 7); do \
 484             echo -n 0000:01:0${device}.${fn} > \
 485             /sys/bus/pci/devices/0000\:01\:0${device}.${fn}/driver/unbind; \
 486         done; \
 487     done
 488
 489 Bind to the DPDK uio driver
 490 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 491
 492 Install the DPDK igb_uio driver, bind the VF PCI Device id to it and use lspci
 493 to confirm the VF devices are now in use by igb_uio kernel driver,
 494 e.g. for the C62x device::
 495
 496     cd to the top-level DPDK directory
 497     modprobe uio
 498     insmod ./build/kmod/igb_uio.ko
 499     echo "8086 37c9" > /sys/bus/pci/drivers/igb_uio/new_id
 500     lspci -vvd:37c9
 501
 502
 503 Another way to bind the VFs to the DPDK UIO driver is by using the
 504 ``dpdk-devbind.py`` script::
 505
 506     cd to the top-level DPDK directory
 507     ./usertools/dpdk-devbind.py -b igb_uio 0000:03:01.1
 508
 509 Testing
 510 ~~~~~~~
 511
 512 QAT crypto PMD can be tested by running the test application::
 513
 514     make defconfig
 515     make test-build -j
 516     cd ./build/app
 517     ./test -l1 -n1 -w <your qat bdf>
 518     RTE>>cryptodev_qat_autotest
 519
 520 QAT compression PMD can be tested by running the test application::
 521
 522     make defconfig
 523     sed -i 's,\(CONFIG_RTE_COMPRESSDEV_TEST\)=n,\1=y,' build/.config
 524     make test-build -j
 525     cd ./build/app
 526     ./test -l1 -n1 -w <your qat bdf>
 527     RTE>>compressdev_autotest
 528
 529
 530 Debugging
 531 ~~~~~~~~~
 532
 533 There are 2 sets of trace available via the dynamic logging feature:
 534
 535 * pmd.qat_dp exposes trace on the data-path.
 536 * pmd.qat_general exposes all other trace.
 537
 538 pmd.qat exposes both sets of traces.
 539 They can be enabled using the log-level option (where 8=maximum log level) on
 540 the process cmdline, e.g. using any of the following::
 541
 542     --log-level="pmd.qat_general,8"
 543     --log-level="pmd.qat_dp,8"
 544     --log-level="pmd.qat,8"
 545
 546 .. Note::
 547
 548     The global RTE_LOG_DP_LEVEL overrides data-path trace so must be set to
 549     RTE_LOG_DEBUG to see all the trace. This variable is in config/rte_config.h
 550     for meson build and config/common_base for gnu make.
 551     Also the dynamic global log level overrides both sets of trace, so e.g. no
 552     QAT trace would display in this case::
 553
 554         --log-level="7" --log-level="pmd.qat_general,8"