+* ZUC EEA3/EIA3 is not supported by dh895xcc devices
+* Maximum additional authenticated data (AAD) for GCM is 240 bytes long.
+* Queue pairs are not thread-safe (that is, within a single queue pair, RX and TX from different lcores is not supported).
+
+
+Extra notes on KASUMI F9
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+When using KASUMI F9 authentication algorithm, the input buffer must be
+constructed according to the
+`3GPP KASUMI specification <http://cryptome.org/3gpp/35201-900.pdf>`_
+(section 4.4, page 13). The input buffer has to have COUNT (4 bytes),
+FRESH (4 bytes), MESSAGE and DIRECTION (1 bit) concatenated. After the DIRECTION
+bit, a single '1' bit is appended, followed by between 0 and 7 '0' bits, so that
+the total length of the buffer is multiple of 8 bits. Note that the actual
+message can be any length, specified in bits.
+
+Once this buffer is passed this way, when creating the crypto operation,
+length of data to authenticate "op.sym.auth.data.length" must be the length
+of all the items described above, including the padding at the end.
+Also, offset of data to authenticate "op.sym.auth.data.offset"
+must be such that points at the start of the COUNT bytes.
+
+
+
+.. _building_qat:
+
+Building PMDs on QAT
+--------------------
+
+A QAT device can host multiple acceleration services:
+
+* symmetric cryptography
+* data compression
+
+These services are provided to DPDK applications via PMDs which register to
+implement the corresponding cryptodev and compressdev APIs. The PMDs use
+common QAT driver code which manages the QAT PCI device. They also depend on a
+QAT kernel driver being installed on the platform, see :ref:`qat_kernel` below.
+
+
+Configuring and Building the DPDK QAT PMDs
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+Further information on configuring, building and installing DPDK is described
+`here <http://dpdk.org/doc/guides/linux_gsg/build_dpdk.html>`_.
+
+
+Quick instructions for QAT cryptodev PMD are as follows:
+
+.. code-block:: console
+
+ cd to the top-level DPDK directory
+ make defconfig
+ sed -i 's,\(CONFIG_RTE_LIBRTE_PMD_QAT_SYM\)=n,\1=y,' build/.config
+ make
+
+Quick instructions for QAT compressdev PMD are as follows:
+
+.. code-block:: console
+
+ cd to the top-level DPDK directory
+ make defconfig
+ make
+
+
+Build Configuration
+~~~~~~~~~~~~~~~~~~~
+
+These are the build configuration options affecting QAT, and their default values:
+
+.. code-block:: console
+
+ CONFIG_RTE_LIBRTE_PMD_QAT=y
+ CONFIG_RTE_LIBRTE_PMD_QAT_SYM=n
+ CONFIG_RTE_PMD_QAT_MAX_PCI_DEVICES=48
+ CONFIG_RTE_PMD_QAT_COMP_SGL_MAX_SEGMENTS=16
+ CONFIG_RTE_PMD_QAT_COMP_IM_BUFFER_SIZE=65536
+
+CONFIG_RTE_LIBRTE_PMD_QAT must be enabled for any QAT PMD to be built.
+
+The QAT cryptodev PMD has an external dependency on libcrypto, so is not
+built by default. CONFIG_RTE_LIBRTE_PMD_QAT_SYM should be enabled to build it.
+
+The QAT compressdev PMD has no external dependencies, so needs no configuration
+options and is built by default.
+
+The number of VFs per PF varies - see table below. If multiple QAT packages are
+installed on a platform then CONFIG_RTE_PMD_QAT_MAX_PCI_DEVICES should be
+adjusted to the number of VFs which the QAT common code will need to handle.
+Note, there are separate config items for max cryptodevs CONFIG_RTE_CRYPTO_MAX_DEVS
+and max compressdevs CONFIG_RTE_COMPRESS_MAX_DEVS, if necessary these should be
+adjusted to handle the total of QAT and other devices which the process will use.
+
+QAT allocates internal structures to handle SGLs. For the compression service
+CONFIG_RTE_PMD_QAT_COMP_SGL_MAX_SEGMENTS can be changed if more segments are needed.
+An extra (max_inflight_ops x 16) bytes per queue_pair will be used for every increment.
+
+QAT compression PMD needs intermediate buffers to support Deflate compression
+with Dynamic Huffman encoding. CONFIG_RTE_PMD_QAT_COMP_IM_BUFFER_SIZE
+specifies the size of a single buffer, the PMD will allocate a multiple of these,
+plus some extra space for associated meta-data. For GEN2 devices, 20 buffers plus
+1472 bytes are allocated.
+
+.. Note::
+
+ If the compressed output of a Deflate operation using Dynamic Huffman
+ Encoding is too big to fit in an intermediate buffer, then the
+ operation will return RTE_COMP_OP_STATUS_ERROR and an error will be
+ displayed. Options for the application in this case
+ are to split the input data into smaller chunks and resubmit
+ in multiple operations or to configure QAT with
+ larger intermediate buffers.
+
+
+Device and driver naming
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+* The qat cryptodev driver name is "crypto_qat".
+ The "rte_cryptodev_devices_get()" returns the devices exposed by this driver.
+
+* Each qat crypto device has a unique name, in format
+ "<pci bdf>_<service>", e.g. "0000:41:01.0_qat_sym".
+ This name can be passed to "rte_cryptodev_get_dev_id()" to get the device_id.
+
+.. Note::
+
+ The qat crypto driver name is passed to the dpdk-test-crypto-perf tool in the "-devtype" parameter.
+
+ The qat crypto device name is in the format of the slave parameter passed to the crypto scheduler.
+
+* The qat compressdev driver name is "compress_qat".
+ The rte_compressdev_devices_get() returns the devices exposed by this driver.
+
+* Each qat compression device has a unique name, in format
+ <pci bdf>_<service>, e.g. "0000:41:01.0_qat_comp".
+ This name can be passed to rte_compressdev_get_dev_id() to get the device_id.
+
+.. _qat_kernel:
+
+Dependency on the QAT kernel driver
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To use QAT an SRIOV-enabled QAT kernel driver is required. The VF
+devices created and initialised by this driver will be used by the QAT PMDs.
+
+Instructions for installation are below, but first an explanation of the
+relationships between the PF/VF devices and the PMDs visible to
+DPDK applications.