net/mlx5: support power monitoring
[dpdk.git] / doc / guides / cryptodevs / qat.rst
1 ..  SPDX-License-Identifier: BSD-3-Clause
2     Copyright(c) 2015-2019 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 and asymmetric crypto services below.
10 * Details of the :doc:`compression service <../compressdevs/qat_comp>`
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 symmetric crypto PMD (hereafter referred to as `QAT SYM [PMD]`) provides
20 poll mode crypto driver support for the following hardware accelerator devices:
21
22 * ``Intel QuickAssist Technology DH895xCC``
23 * ``Intel QuickAssist Technology C62x``
24 * ``Intel QuickAssist Technology C3xxx``
25 * ``Intel QuickAssist Technology 200xx``
26 * ``Intel QuickAssist Technology D15xx``
27 * ``Intel QuickAssist Technology C4xxx``
28
29
30 Features
31 ~~~~~~~~
32
33 The QAT SYM PMD has support for:
34
35 Cipher algorithms:
36
37 * ``RTE_CRYPTO_CIPHER_3DES_CBC``
38 * ``RTE_CRYPTO_CIPHER_3DES_CTR``
39 * ``RTE_CRYPTO_CIPHER_AES128_CBC``
40 * ``RTE_CRYPTO_CIPHER_AES192_CBC``
41 * ``RTE_CRYPTO_CIPHER_AES256_CBC``
42 * ``RTE_CRYPTO_CIPHER_AES128_CTR``
43 * ``RTE_CRYPTO_CIPHER_AES192_CTR``
44 * ``RTE_CRYPTO_CIPHER_AES256_CTR``
45 * ``RTE_CRYPTO_CIPHER_AES_XTS``
46 * ``RTE_CRYPTO_CIPHER_SNOW3G_UEA2``
47 * ``RTE_CRYPTO_CIPHER_NULL``
48 * ``RTE_CRYPTO_CIPHER_KASUMI_F8``
49 * ``RTE_CRYPTO_CIPHER_DES_CBC``
50 * ``RTE_CRYPTO_CIPHER_AES_DOCSISBPI``
51 * ``RTE_CRYPTO_CIPHER_DES_DOCSISBPI``
52 * ``RTE_CRYPTO_CIPHER_ZUC_EEA3``
53
54 Hash algorithms:
55
56 * ``RTE_CRYPTO_AUTH_SHA1``
57 * ``RTE_CRYPTO_AUTH_SHA1_HMAC``
58 * ``RTE_CRYPTO_AUTH_SHA224``
59 * ``RTE_CRYPTO_AUTH_SHA224_HMAC``
60 * ``RTE_CRYPTO_AUTH_SHA256``
61 * ``RTE_CRYPTO_AUTH_SHA256_HMAC``
62 * ``RTE_CRYPTO_AUTH_SHA384``
63 * ``RTE_CRYPTO_AUTH_SHA384_HMAC``
64 * ``RTE_CRYPTO_AUTH_SHA512``
65 * ``RTE_CRYPTO_AUTH_SHA512_HMAC``
66 * ``RTE_CRYPTO_AUTH_AES_XCBC_MAC``
67 * ``RTE_CRYPTO_AUTH_SNOW3G_UIA2``
68 * ``RTE_CRYPTO_AUTH_MD5_HMAC``
69 * ``RTE_CRYPTO_AUTH_NULL``
70 * ``RTE_CRYPTO_AUTH_KASUMI_F9``
71 * ``RTE_CRYPTO_AUTH_AES_GMAC``
72 * ``RTE_CRYPTO_AUTH_ZUC_EIA3``
73 * ``RTE_CRYPTO_AUTH_AES_CMAC``
74
75 Supported AEAD algorithms:
76
77 * ``RTE_CRYPTO_AEAD_AES_GCM``
78 * ``RTE_CRYPTO_AEAD_AES_CCM``
79 * ``RTE_CRYPTO_AEAD_CHACHA20_POLY1305``
80
81 Protocol offloads:
82
83 * ``RTE_SECURITY_PROTOCOL_DOCSIS``
84
85 Supported Chains
86 ~~~~~~~~~~~~~~~~
87
88 All the usual chains are supported and also some mixed chains:
89
90 .. table:: Supported hash-cipher chains for wireless digest-encrypted cases
91
92    +------------------+-----------+-------------+----------+----------+
93    | Cipher algorithm | NULL AUTH | SNOW3G UIA2 | ZUC EIA3 | AES CMAC |
94    +==================+===========+=============+==========+==========+
95    | NULL CIPHER      | Y         | 2&3         | 2&3      | Y        |
96    +------------------+-----------+-------------+----------+----------+
97    | SNOW3G UEA2      | 2&3       | Y           | 2&3      | 2&3      |
98    +------------------+-----------+-------------+----------+----------+
99    | ZUC EEA3         | 2&3       | 2&3         | 2&3      | 2&3      |
100    +------------------+-----------+-------------+----------+----------+
101    | AES CTR          | Y         | 2&3         | 2&3      | Y        |
102    +------------------+-----------+-------------+----------+----------+
103
104 * The combinations marked as "Y" are supported on all QAT hardware versions.
105 * The combinations marked as "2&3" are supported on GEN2/GEN3 QAT hardware only.
106
107
108 Limitations
109 ~~~~~~~~~~~
110
111 * Only supports the session-oriented API implementation (session-less APIs are not supported).
112 * SNOW 3G (UEA2), KASUMI (F8) and ZUC (EEA3) supported only if cipher length and offset fields are byte-multiple.
113 * SNOW 3G (UIA2) and ZUC (EIA3) supported only if hash length and offset fields are byte-multiple.
114 * No BSD support as BSD QAT kernel driver not available.
115 * ZUC EEA3/EIA3 is not supported by dh895xcc devices
116 * Maximum additional authenticated data (AAD) for GCM is 240 bytes long and must be passed to the device in a buffer rounded up to the nearest block-size multiple (x16) and padded with zeros.
117 * Queue-pairs are thread-safe on Intel CPUs but Queues are not (that is, within a single
118   queue-pair all enqueues to the TX queue must be done from one thread and all dequeues
119   from the RX queue must be done from one thread, but enqueues and dequeues may be done
120   in different threads.)
121 * A GCM limitation exists, but only in the case where there are multiple
122   generations of QAT devices on a single platform.
123   To optimise performance, the GCM crypto session should be initialised for the
124   device generation to which the ops will be enqueued. Specifically if a GCM
125   session is initialised on a GEN2 device, but then attached to an op enqueued
126   to a GEN3 device, it will work but cannot take advantage of hardware
127   optimisations in the GEN3 device. And if a GCM session is initialised on a
128   GEN3 device, then attached to an op sent to a GEN1/GEN2 device, it will not be
129   enqueued to the device and will be marked as failed. The simplest way to
130   mitigate this is to use the PCI allowlist to avoid mixing devices of different
131   generations in the same process if planning to use for GCM.
132 * The mixed algo feature on GEN2 is not supported by all kernel drivers. Check
133   the notes under the Available Kernel Drivers table below for specific details.
134 * Out-of-place is not supported for combined Crypto-CRC DOCSIS security
135   protocol.
136 * ``RTE_CRYPTO_CIPHER_DES_DOCSISBPI`` is not supported for combined Crypto-CRC
137   DOCSIS security protocol.
138 * Multi-segment buffers are not supported for combined Crypto-CRC DOCSIS
139   security protocol.
140
141 Extra notes on KASUMI F9
142 ~~~~~~~~~~~~~~~~~~~~~~~~
143
144 When using KASUMI F9 authentication algorithm, the input buffer must be
145 constructed according to the
146 `3GPP KASUMI specification <http://cryptome.org/3gpp/35201-900.pdf>`_
147 (section 4.4, page 13). The input buffer has to have COUNT (4 bytes),
148 FRESH (4 bytes), MESSAGE and DIRECTION (1 bit) concatenated. After the DIRECTION
149 bit, a single '1' bit is appended, followed by between 0 and 7 '0' bits, so that
150 the total length of the buffer is multiple of 8 bits. Note that the actual
151 message can be any length, specified in bits.
152
153 Once this buffer is passed this way, when creating the crypto operation,
154 length of data to authenticate "op.sym.auth.data.length" must be the length
155 of all the items described above, including the padding at the end.
156 Also, offset of data to authenticate "op.sym.auth.data.offset"
157 must be such that points at the start of the COUNT bytes.
158
159 Asymmetric Crypto Service on QAT
160 --------------------------------
161
162 The QAT asymmetric crypto PMD (hereafter referred to as `QAT ASYM [PMD]`) provides
163 poll mode crypto driver support for the following hardware accelerator devices:
164
165 * ``Intel QuickAssist Technology DH895xCC``
166 * ``Intel QuickAssist Technology C62x``
167 * ``Intel QuickAssist Technology C3xxx``
168 * ``Intel QuickAssist Technology D15xx``
169 * ``Intel QuickAssist Technology C4xxx``
170
171 The QAT ASYM PMD has support for:
172
173 * ``RTE_CRYPTO_ASYM_XFORM_MODEX``
174 * ``RTE_CRYPTO_ASYM_XFORM_MODINV``
175
176 Limitations
177 ~~~~~~~~~~~
178
179 * Big integers longer than 4096 bits are not supported.
180 * Queue-pairs are thread-safe on Intel CPUs but Queues are not (that is, within a single
181   queue-pair all enqueues to the TX queue must be done from one thread and all dequeues
182   from the RX queue must be done from one thread, but enqueues and dequeues may be done
183   in different threads.)
184 * RSA-2560, RSA-3584 are not supported
185
186 .. _building_qat:
187
188 Building PMDs on QAT
189 --------------------
190
191 A QAT device can host multiple acceleration services:
192
193 * symmetric cryptography
194 * data compression
195 * asymmetric cryptography
196
197 These services are provided to DPDK applications via PMDs which register to
198 implement the corresponding cryptodev and compressdev APIs. The PMDs use
199 common QAT driver code which manages the QAT PCI device. They also depend on a
200 QAT kernel driver being installed on the platform, see :ref:`qat_kernel` below.
201
202
203 Configuring and Building the DPDK QAT PMDs
204 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
205
206
207 Further information on configuring, building and installing DPDK is described
208 :doc:`here <../linux_gsg/build_dpdk>`.
209
210 .. _building_qat_config:
211
212 Build Configuration
213 ~~~~~~~~~~~~~~~~~~~
214
215 These are the build configuration options affecting QAT, and their default values:
216
217 .. code-block:: console
218
219         RTE_PMD_QAT_MAX_PCI_DEVICES=48
220         RTE_PMD_QAT_COMP_IM_BUFFER_SIZE=65536
221
222 Both QAT SYM PMD and QAT ASYM PMD have an external dependency on libcrypto, so are not
223 built by default.
224
225 The QAT compressdev PMD has no external dependencies, so is built by default.
226
227 The number of VFs per PF varies - see table below. If multiple QAT packages are
228 installed on a platform then RTE_PMD_QAT_MAX_PCI_DEVICES should be
229 adjusted to the number of VFs which the QAT common code will need to handle.
230
231 .. Note::
232
233         There are separate config items (not QAT-specific) for max cryptodevs
234         RTE_CRYPTO_MAX_DEVS and max compressdevs RTE_COMPRESS_MAX_DEVS,
235         if necessary these should be adjusted to handle the total of QAT and other
236         devices which the process will use. In particular for crypto, where each
237         QAT VF may expose two crypto devices, sym and asym, it may happen that the
238         number of devices will be bigger than MAX_DEVS and the process will show an error
239         during PMD initialisation. To avoid this problem RTE_CRYPTO_MAX_DEVS may be
240         increased or -a, allow domain:bus:devid:func option may be used.
241
242
243 QAT compression PMD needs intermediate buffers to support Deflate compression
244 with Dynamic Huffman encoding. RTE_PMD_QAT_COMP_IM_BUFFER_SIZE
245 specifies the size of a single buffer, the PMD will allocate a multiple of these,
246 plus some extra space for associated meta-data. For GEN2 devices, 20 buffers are
247 allocated while for GEN1 devices, 12 buffers are allocated, plus 1472 bytes overhead.
248
249 .. Note::
250
251         If the compressed output of a Deflate operation using Dynamic Huffman
252         Encoding is too big to fit in an intermediate buffer, then the
253         operation will be split into smaller operations and their results will
254         be merged afterwards.
255         This is not possible if any checksum calculation was requested - in such
256         case the code falls back to fixed compression.
257         To avoid this less performant case, applications should configure
258         the intermediate buffer size to be larger than the expected input data size
259         (compressed output size is usually unknown, so the only option is to make
260         larger than the input size).
261
262
263 Running QAT PMD with minimum threshold for burst size
264 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
265
266 If only a small number or packets can be enqueued. Each enqueue causes an expensive MMIO write.
267 These MMIO write occurrences can be optimised by setting any of the following parameters:
268
269 - qat_sym_enq_threshold
270 - qat_asym_enq_threshold
271 - qat_comp_enq_threshold
272
273 When any of these parameters is set rte_cryptodev_enqueue_burst function will
274 return 0 (thereby avoiding an MMIO) if the device is congested and number of packets
275 possible to enqueue is smaller.
276 To use this feature the user must set the parameter on process start as a device additional parameter::
277
278   -a 03:01.1,qat_sym_enq_threshold=32,qat_comp_enq_threshold=16
279
280 All parameters can be used with the same device regardless of order. Parameters are separated
281 by comma. When the same parameter is used more than once first occurrence of the parameter
282 is used.
283 Maximum threshold that can be set is 32.
284
285
286 Device and driver naming
287 ~~~~~~~~~~~~~~~~~~~~~~~~
288
289 * The qat cryptodev symmetric crypto driver name is "crypto_qat".
290 * The qat cryptodev asymmetric crypto driver name is "crypto_qat_asym".
291
292 The "rte_cryptodev_devices_get()" returns the devices exposed by either of these drivers.
293
294 * Each qat sym crypto device has a unique name, in format
295   "<pci bdf>_<service>", e.g. "0000:41:01.0_qat_sym".
296 * Each qat asym crypto device has a unique name, in format
297   "<pci bdf>_<service>", e.g. "0000:41:01.0_qat_asym".
298   This name can be passed to "rte_cryptodev_get_dev_id()" to get the device_id.
299
300 .. Note::
301
302         The cryptodev driver name is passed to the dpdk-test-crypto-perf tool in the "-devtype" parameter.
303
304         The qat crypto device name is in the format of the worker parameter passed to the crypto scheduler.
305
306 * The qat compressdev driver name is "compress_qat".
307   The rte_compressdev_devices_get() returns the devices exposed by this driver.
308
309 * Each qat compression device has a unique name, in format
310   <pci bdf>_<service>, e.g. "0000:41:01.0_qat_comp".
311   This name can be passed to rte_compressdev_get_dev_id() to get the device_id.
312
313 .. _qat_kernel:
314
315 Dependency on the QAT kernel driver
316 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
317
318 To use QAT an SRIOV-enabled QAT kernel driver is required. The VF
319 devices created and initialised by this driver will be used by the QAT PMDs.
320
321 Instructions for installation are below, but first an explanation of the
322 relationships between the PF/VF devices and the PMDs visible to
323 DPDK applications.
324
325 Each QuickAssist PF device exposes a number of VF devices. Each VF device can
326 enable one symmetric cryptodev PMD and/or one asymmetric cryptodev PMD and/or
327 one compressdev PMD.
328 These QAT PMDs share the same underlying device and pci-mgmt code, but are
329 enumerated independently on their respective APIs and appear as independent
330 devices to applications.
331
332 .. Note::
333
334    Each VF can only be used by one DPDK process. It is not possible to share
335    the same VF across multiple processes, even if these processes are using
336    different acceleration services.
337
338    Conversely one DPDK process can use one or more QAT VFs and can expose both
339    cryptodev and compressdev instances on each of those VFs.
340
341
342 Available kernel drivers
343 ~~~~~~~~~~~~~~~~~~~~~~~~
344
345 Kernel drivers for each device for each service are listed in the following table. (Scroll right
346 to see the full table)
347
348
349 .. _table_qat_pmds_drivers:
350
351 .. table:: QAT device generations, devices and drivers
352
353    +-----+-----+-----+-----+----------+---------------+---------------+------------+--------+------+--------+--------+
354    | S   | A   | C   | Gen | Device   | Driver/ver    | Kernel Module | Pci Driver | PF Did | #PFs | VF Did | VFs/PF |
355    +=====+=====+=====+=====+==========+===============+===============+============+========+======+========+========+
356    | Yes | No  | No  | 1   | DH895xCC | linux/4.4+    | qat_dh895xcc  | dh895xcc   | 435    | 1    | 443    | 32     |
357    +-----+-----+-----+-----+----------+---------------+---------------+------------+--------+------+--------+--------+
358    | Yes | Yes | No  | "   | "        | 01.org/4.2.0+ | "             | "          | "      | "    | "      | "      |
359    +-----+-----+-----+-----+----------+---------------+---------------+------------+--------+------+--------+--------+
360    | Yes | Yes | Yes | "   | "        | 01.org/4.3.0+ | "             | "          | "      | "    | "      | "      |
361    +-----+-----+-----+-----+----------+---------------+---------------+------------+--------+------+--------+--------+
362    | Yes | No  | No  | 2   | C62x     | linux/4.5+    | qat_c62x      | c6xx       | 37c8   | 3    | 37c9   | 16     |
363    +-----+-----+-----+-----+----------+---------------+---------------+------------+--------+------+--------+--------+
364    | Yes | Yes | Yes | "   | "        | 01.org/4.2.0+ | "             | "          | "      | "    | "      | "      |
365    +-----+-----+-----+-----+----------+---------------+---------------+------------+--------+------+--------+--------+
366    | Yes | No  | No  | 2   | C3xxx    | linux/4.5+    | qat_c3xxx     | c3xxx      | 19e2   | 1    | 19e3   | 16     |
367    +-----+-----+-----+-----+----------+---------------+---------------+------------+--------+------+--------+--------+
368    | Yes | Yes | Yes | "   | "        | 01.org/4.2.0+ | "             | "          | "      | "    | "      | "      |
369    +-----+-----+-----+-----+----------+---------------+---------------+------------+--------+------+--------+--------+
370    | Yes | No  | No  | 2   | 200xx    | p             | qat_200xx     | 200xx      | 18ee   | 1    | 18ef   | 16     |
371    +-----+-----+-----+-----+----------+---------------+---------------+------------+--------+------+--------+--------+
372    | Yes | No  | No  | 2   | D15xx    | 01.org/4.2.0+ | qat_d15xx     | d15xx      | 6f54   | 1    | 6f55   | 16     |
373    +-----+-----+-----+-----+----------+---------------+---------------+------------+--------+------+--------+--------+
374    | Yes | No  | No  | 3   | C4xxx    | p             | qat_c4xxx     | c4xxx      | 18a0   | 1    | 18a1   | 128    |
375    +-----+-----+-----+-----+----------+---------------+---------------+------------+--------+------+--------+--------+
376
377 * Note: Symmetric mixed crypto algorithms feature on Gen 2 works only with 01.org driver version 4.9.0+
378
379 The first 3 columns indicate the service:
380
381 * S = Symmetric crypto service (via cryptodev API)
382 * A = Asymmetric crypto service  (via cryptodev API)
383 * C = Compression service (via compressdev API)
384
385 The ``Driver`` column indicates either the Linux kernel version in which
386 support for this device was introduced or a driver available on Intel's 01.org
387 website. There are both linux in-tree and 01.org kernel drivers available for some
388 devices. p = release pending.
389
390 If you are running on a kernel which includes a driver for your device, see
391 `Installation using kernel.org driver`_ below. Otherwise see
392 `Installation using 01.org QAT driver`_.
393
394
395 Installation using kernel.org driver
396 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
397
398 The examples below are based on the C62x device, if you have a different device
399 use the corresponding values in the above table.
400
401 In BIOS ensure that SRIOV is enabled and either:
402
403 * Disable VT-d or
404 * Enable VT-d and set ``"intel_iommu=on iommu=pt"`` in the grub file.
405
406 Check that the QAT driver is loaded on your system, by executing::
407
408     lsmod | grep qa
409
410 You should see the kernel module for your device listed, e.g.::
411
412     qat_c62x               5626  0
413     intel_qat              82336  1 qat_c62x
414
415 Next, you need to expose the Virtual Functions (VFs) using the sysfs file system.
416
417 First find the BDFs (Bus-Device-Function) of the physical functions (PFs) of
418 your device, e.g.::
419
420     lspci -d:37c8
421
422 You should see output similar to::
423
424     1a:00.0 Co-processor: Intel Corporation Device 37c8
425     3d:00.0 Co-processor: Intel Corporation Device 37c8
426     3f:00.0 Co-processor: Intel Corporation Device 37c8
427
428 Enable the VFs for each PF by echoing the number of VFs per PF to the pci driver::
429
430      echo 16 > /sys/bus/pci/drivers/c6xx/0000:1a:00.0/sriov_numvfs
431      echo 16 > /sys/bus/pci/drivers/c6xx/0000:3d:00.0/sriov_numvfs
432      echo 16 > /sys/bus/pci/drivers/c6xx/0000:3f:00.0/sriov_numvfs
433
434 Check that the VFs are available for use. For example ``lspci -d:37c9`` should
435 list 48 VF devices available for a ``C62x`` device.
436
437 To complete the installation follow the instructions in
438 `Binding the available VFs to the vfio-pci driver`_.
439
440 .. Note::
441
442    If the QAT kernel modules are not loaded and you see an error like ``Failed
443    to load MMP firmware qat_895xcc_mmp.bin`` in kernel logs, this may be as a
444    result of not using a distribution, but just updating the kernel directly.
445
446    Download firmware from the `kernel firmware repo
447    <http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/>`_.
448
449    Copy qat binaries to ``/lib/firmware``::
450
451       cp qat_895xcc.bin /lib/firmware
452       cp qat_895xcc_mmp.bin /lib/firmware
453
454    Change to your linux source root directory and start the qat kernel modules::
455
456       insmod ./drivers/crypto/qat/qat_common/intel_qat.ko
457       insmod ./drivers/crypto/qat/qat_dh895xcc/qat_dh895xcc.ko
458
459 .. Note::
460
461    If you see the following warning in ``/var/log/messages`` it can be ignored:
462    ``IOMMU should be enabled for SR-IOV to work correctly``.
463
464
465 Installation using 01.org QAT driver
466 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
467
468 Download the latest QuickAssist Technology Driver from `01.org
469 <https://01.org/packet-processing/intel%C2%AE-quickassist-technology-drivers-and-patches>`_.
470 Consult the *Getting Started Guide* at the same URL for further information.
471
472 The steps below assume you are:
473
474 * Building on a platform with one ``C62x`` device.
475 * Using package ``qat1.7.l.4.2.0-000xx.tar.gz``.
476 * On Fedora26 kernel ``4.11.11-300.fc26.x86_64``.
477
478 In the BIOS ensure that SRIOV is enabled and VT-d is disabled.
479
480 Uninstall any existing QAT driver, for example by running:
481
482 * ``./installer.sh uninstall`` in the directory where originally installed.
483
484
485 Build and install the SRIOV-enabled QAT driver::
486
487     mkdir /QAT
488     cd /QAT
489
490     # Copy the package to this location and unpack
491     tar zxof qat1.7.l.4.2.0-000xx.tar.gz
492
493     ./configure --enable-icp-sriov=host
494     make install
495
496 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.
497 You can use ``lspci -d:37c9`` to confirm the presence of the 16 VF devices available per ``C62x`` PF.
498
499 Confirm the driver is correctly installed and is using firmware version 4.2.0::
500
501     cat /sys/kernel/debug/qat<your device type and bdf>/version/fw
502
503
504 Confirm the presence of 48 VF devices - 16 per PF::
505
506     lspci -d:37c9
507
508
509 To complete the installation - follow instructions in
510 `Binding the available VFs to the vfio-pci driver`_.
511
512 .. Note::
513
514    If using a later kernel and the build fails with an error relating to
515    ``strict_stroul`` not being available apply the following patch:
516
517    .. code-block:: diff
518
519       /QAT/QAT1.6/quickassist/utilities/downloader/Target_CoreLibs/uclo/include/linux/uclo_platform.h
520       + #if LINUX_VERSION_CODE >= KERNEL_VERSION(3,18,5)
521       + #define STR_TO_64(str, base, num, endPtr) {endPtr=NULL; if (kstrtoul((str), (base), (num))) printk("Error strtoull convert %s\n", str); }
522       + #else
523       #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,38)
524       #define STR_TO_64(str, base, num, endPtr) {endPtr=NULL; if (strict_strtoull((str), (base), (num))) printk("Error strtoull convert %s\n", str); }
525       #else
526       #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,25)
527       #define STR_TO_64(str, base, num, endPtr) {endPtr=NULL; strict_strtoll((str), (base), (num));}
528       #else
529       #define STR_TO_64(str, base, num, endPtr)                                 \
530            do {                                                               \
531                  if (str[0] == '-')                                           \
532                  {                                                            \
533                       *(num) = -(simple_strtoull((str+1), &(endPtr), (base))); \
534                  }else {                                                      \
535                       *(num) = simple_strtoull((str), &(endPtr), (base));      \
536                  }                                                            \
537            } while(0)
538       + #endif
539       #endif
540       #endif
541
542
543 .. Note::
544
545    If the build fails due to missing header files you may need to do following::
546
547       sudo yum install zlib-devel
548       sudo yum install openssl-devel
549       sudo yum install libudev-devel
550
551 .. Note::
552
553    If the build or install fails due to mismatching kernel sources you may need to do the following::
554
555       sudo yum install kernel-headers-`uname -r`
556       sudo yum install kernel-src-`uname -r`
557       sudo yum install kernel-devel-`uname -r`
558
559
560 Binding the available VFs to the vfio-pci driver
561 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
562
563 Note:
564
565 * Please note that due to security issues, the usage of older DPDK igb_uio
566   driver is not recommended. This document shows how to use the more secure
567   vfio-pci driver.
568 * If QAT fails to bind to vfio-pci on Linux kernel 5.9+, please see the
569   QATE-39220 and QATE-7495 issues in
570   `01.org doc <https://01.org/sites/default/files/downloads/336211-015-qatsoftwareforlinux-rn-hwv1.7-final.pdf>`_
571   which details the constraint about trusted guests and add `disable_denylist=1`
572   to the vfio-pci params to use QAT. See also `this patch description <https://lkml.org/lkml/2020/7/23/1155>`_.
573
574 Unbind the VFs from the stock driver so they can be bound to the vfio-pci driver.
575
576 For an Intel(R) QuickAssist Technology DH895xCC device
577 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
578
579 The unbind command below assumes ``BDFs`` of ``03:01.00-03:04.07``, if your
580 VFs are different adjust the unbind command below::
581
582     cd to the top-level DPDK directory
583     for device in $(seq 1 4); do \
584         for fn in $(seq 0 7); do \
585             usertools/dpdk-devbind.py -u 0000:03:0${device}.${fn}; \
586         done; \
587     done
588
589 For an Intel(R) QuickAssist Technology C62x device
590 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
591
592 The unbind command below assumes ``BDFs`` of ``1a:01.00-1a:02.07``,
593 ``3d:01.00-3d:02.07`` and ``3f:01.00-3f:02.07``, if your VFs are different
594 adjust the unbind command below::
595
596     cd to the top-level DPDK directory
597     for device in $(seq 1 2); do \
598         for fn in $(seq 0 7); do \
599             usertools/dpdk-devbind.py -u 0000:1a:0${device}.${fn}; \
600             usertools/dpdk-devbind.py -u 0000:3d:0${device}.${fn}; \
601             usertools/dpdk-devbind.py -u 0000:3f:0${device}.${fn}; \
602         done; \
603     done
604
605 For Intel(R) QuickAssist Technology C3xxx or 200xx or D15xx device
606 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
607
608 The unbind command below assumes ``BDFs`` of ``01:01.00-01:02.07``, if your
609 VFs are different adjust the unbind command below::
610
611     cd to the top-level DPDK directory
612     for device in $(seq 1 2); do \
613         for fn in $(seq 0 7); do \
614             usertools/dpdk-devbind.py -u 0000:01:0${device}.${fn}; \
615         done; \
616     done
617
618 Bind to the vfio-pci driver
619 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
620
621 Load the vfio-pci driver, bind the VF PCI Device id to it using the
622 ``dpdk-devbind.py`` script then use the ``--status`` option
623 to confirm the VF devices are now in use by vfio-pci kernel driver,
624 e.g. for the C62x device::
625
626     cd to the top-level DPDK directory
627     modprobe vfio-pci
628     usertools/dpdk-devbind.py -b vfio-pci 0000:03:01.1
629     usertools/dpdk-devbind.py --status
630
631 Use ``modprobe vfio-pci disable_denylist=1`` from kernel 5.9 onwards.
632 See note in the section `Binding the available VFs to the vfio-pci driver`_
633 above.
634
635 Testing
636 ~~~~~~~
637
638 QAT SYM crypto PMD can be tested by running the test application::
639
640     cd ./<build_dir>/app/test
641     ./dpdk-test -l1 -n1 -a <your qat bdf>
642     RTE>>cryptodev_qat_autotest
643
644 QAT ASYM crypto PMD can be tested by running the test application::
645
646     cd ./<build_dir>/app/test
647     ./dpdk-test -l1 -n1 -a <your qat bdf>
648     RTE>>cryptodev_qat_asym_autotest
649
650 QAT compression PMD can be tested by running the test application::
651
652     cd ./<build_dir>/app/test
653     ./dpdk-test -l1 -n1 -a <your qat bdf>
654     RTE>>compressdev_autotest
655
656
657 Debugging
658 ~~~~~~~~~
659
660 There are 2 sets of trace available via the dynamic logging feature:
661
662 * pmd.qat.dp exposes trace on the data-path.
663 * pmd.qat.general exposes all other trace.
664
665 pmd.qat exposes both sets of traces.
666 They can be enabled using the log-level option (where 8=maximum log level) on
667 the process cmdline, e.g. using any of the following::
668
669     --log-level="pmd.qat.general,8"
670     --log-level="pmd.qat.dp,8"
671     --log-level="pmd.qat,8"
672
673 .. Note::
674
675     The global RTE_LOG_DP_LEVEL overrides data-path trace so must be set to
676     RTE_LOG_DEBUG to see all the trace. This variable is in config/rte_config.h
677     for meson build.
678     Also the dynamic global log level overrides both sets of trace, so e.g. no
679     QAT trace would display in this case::
680
681         --log-level="7" --log-level="pmd.qat.general,8"