diff options
Diffstat (limited to 'doc/guides')
97 files changed, 5619 insertions, 1308 deletions
diff --git a/doc/guides/compressdevs/features/octeontx.ini b/doc/guides/compressdevs/features/octeontx.ini index 884a8b07..cc8b0256 100644 --- a/doc/guides/compressdevs/features/octeontx.ini +++ b/doc/guides/compressdevs/features/octeontx.ini @@ -1,7 +1,7 @@ ; ; Refer to default.ini for the full list of available PMD features. ; -; Supported features of 'OCTEONTX ZIP' compression driver. +; Supported features of 'OCTEON TX ZIP' compression driver. ; [Features] HW Accelerated = Y diff --git a/doc/guides/compressdevs/features/qat.ini b/doc/guides/compressdevs/features/qat.ini index 5cd4524b..6b1e7f93 100644 --- a/doc/guides/compressdevs/features/qat.ini +++ b/doc/guides/compressdevs/features/qat.ini @@ -13,3 +13,4 @@ Adler32 = Y Crc32 = Y Adler32&Crc32 = Y Fixed = Y +Dynamic = Y diff --git a/doc/guides/compressdevs/octeontx.rst b/doc/guides/compressdevs/octeontx.rst index 5a32d5d1..05dbd681 100644 --- a/doc/guides/compressdevs/octeontx.rst +++ b/doc/guides/compressdevs/octeontx.rst @@ -1,12 +1,12 @@ .. SPDX-License-Identifier: BSD-3-Clause Copyright(c) 2018 Cavium Networks. -Octeontx ZIP Compression Poll Mode Driver -========================================= +OCTEON TX ZIP Compression Poll Mode Driver +========================================== -The Octeontx ZIP PMD (**librte_pmd_octeontx_zip**) provides poll mode +The OCTEON TX ZIP PMD (**librte_pmd_octeontx_zip**) provides poll mode compression & decompression driver for ZIP HW offload device, found in -**Cavium OCTEONTX** SoC family. +**Cavium OCTEON TX** SoC family. More information can be found at `Cavium, Inc Official Website <http://www.cavium.com/OCTEON-TX_ARM_Processors.html>`_. @@ -14,7 +14,7 @@ More information can be found at `Cavium, Inc Official Website Features -------- -Octeontx ZIP PMD has support for: +OCTEON TX ZIP PMD has support for: Compression/Decompression algorithm: @@ -34,24 +34,24 @@ Limitations * Chained mbufs are not supported. -Supported OCTEONTX SoCs ------------------------ +Supported OCTEON TX SoCs +------------------------ - CN83xx Steps To Setup Platform ----------------------- - Octeontx SDK includes kernel image which provides Octeontx ZIP PF + OCTEON TX SDK includes kernel image which provides OCTEON TX ZIP PF driver to manage configuration of ZIPVF device Required version of SDK is "OCTEONTX-SDK-6.2.0-build35" or above. SDK can be install by using below command. - #rpm -ivh CTEONTX-SDK-6.2.0-build35.x86_64.rpm --force --nodeps + #rpm -ivh OCTEONTX-SDK-6.2.0-build35.x86_64.rpm --force --nodeps It will install OCTEONTX-SDK at following default location /usr/local/Cavium_Networks/OCTEONTX-SDK/ - For more information on building and booting linux kernel on OCTEONTX + For more information on building and booting linux kernel on OCTEON TX please refer /usr/local/Cavium_Networks/OCTEONTX-SDK/docs/OcteonTX-SDK-UG_6.2.0.pdf. SDK and related information can be obtained from: `Cavium support site <https://support.cavium.com/>`_. @@ -62,7 +62,7 @@ Installation Driver Compilation ~~~~~~~~~~~~~~~~~~ -To compile the OCTEONTX ZIP PMD for Linux arm64 gcc target, run the +To compile the OCTEON TX ZIP PMD for Linux arm64 gcc target, run the following ``make`` command: .. code-block:: console @@ -74,7 +74,7 @@ following ``make`` command: Initialization -------------- -The octeontx zip is exposed as pci device which consists of a set of +The OCTEON TX zip is exposed as pci device which consists of a set of PCIe VF devices. On EAL initialization, ZIP PCIe VF devices will be probed. To use the PMD in an application, user must: diff --git a/doc/guides/compressdevs/qat_comp.rst b/doc/guides/compressdevs/qat_comp.rst index 8b1270b7..aee3b99b 100644 --- a/doc/guides/compressdevs/qat_comp.rst +++ b/doc/guides/compressdevs/qat_comp.rst @@ -18,11 +18,7 @@ QAT compression PMD has support for: Compression/Decompression algorithm: - * DEFLATE - -Huffman code type: - - * FIXED + * DEFLATE - using Fixed and Dynamic Huffman encoding Window size support: @@ -36,12 +32,13 @@ Limitations ----------- * Compressdev level 0, no compression, is not supported. +* Queue pairs are not thread-safe (that is, within a single queue pair, RX and TX from different lcores is not supported). +* No BSD support as BSD QAT kernel driver not available. -* Dynamic Huffman encoding is not yet supported. Installation ------------ The QAT compression PMD is built by default with a standard DPDK build. -It depends on a QAT kernel driver, see :ref:`qat_kernel_installation`. +It depends on a QAT kernel driver, see :ref:`building_qat`. diff --git a/doc/guides/contributing/coding_style.rst b/doc/guides/contributing/coding_style.rst index b1bf0d15..19445c11 100644 --- a/doc/guides/contributing/coding_style.rst +++ b/doc/guides/contributing/coding_style.rst @@ -741,8 +741,8 @@ A specialization looks like this: * PF/VF mailbox output: ``type.section.name.mbox`` A real world example is the i40e poll mode driver which exposes two -specializations, one for initialization ``pmd.i40e.init`` and the other for -the remaining driver logs ``pmd.i40e.driver``. +specializations, one for initialization ``pmd.net.i40e.init`` and the other for +the remaining driver logs ``pmd.net.i40e.driver``. Note that specializations have no formatting rules, but please follow a precedent if one exists. In order to see all current log topics and diff --git a/doc/guides/contributing/documentation.rst b/doc/guides/contributing/documentation.rst index 6a075553..0165990e 100644 --- a/doc/guides/contributing/documentation.rst +++ b/doc/guides/contributing/documentation.rst @@ -297,8 +297,8 @@ Line Length testpmd -l 2-3 -n 4 \ --vdev=virtio_user0,path=/dev/vhost-net,queues=2,queue_size=1024 \ - -- -i --txqflags=0x0 --enable-hw-vlan --enable-lro \ - --enable-rx-cksum --txq=2 --rxq=2 --rxd=1024 --txd=1024 + -- -i --tx-offloads=0x0000002c --enable-lro --txq=2 --rxq=2 \ + --txd=1024 --rxd=1024 Whitespace @@ -615,19 +615,14 @@ The following are some guidelines for use of Doxygen in the DPDK API documentati .. code-block:: c /** - * Attach a new Ethernet device specified by arguments. - * - * @param devargs - * A pointer to a strings array describing the new device - * to be attached. The strings should be a pci address like - * `0000:01:00.0` or **virtual** device name like `net_pcap0`. - * @param port_id - * A pointer to a port identifier actually attached. + * Try to take the lock. * + * @param sl + * A pointer to the spinlock. * @return - * 0 on success and port_id is filled, negative on error. + * 1 if the lock is successfully taken; 0 otherwise. */ - int rte_eth_dev_attach(const char *devargs, uint8_t *port_id); + int rte_spinlock_trylock(rte_spinlock_t *sl); * Doxygen supports Markdown style syntax such as bold, italics, fixed width text and lists. For example the second line in the ``devargs`` parameter in the previous example will be rendered as: diff --git a/doc/guides/cryptodevs/aesni_mb.rst b/doc/guides/cryptodevs/aesni_mb.rst index c2929500..63e060d7 100644 --- a/doc/guides/cryptodevs/aesni_mb.rst +++ b/doc/guides/cryptodevs/aesni_mb.rst @@ -44,6 +44,7 @@ Hash algorithms: AEAD algorithms: * RTE_CRYPTO_AEAD_AES_CCM +* RTE_CRYPTO_AEAD_AES_GCM Limitations ----------- diff --git a/doc/guides/cryptodevs/caam_jr.rst b/doc/guides/cryptodevs/caam_jr.rst new file mode 100644 index 00000000..e87ff091 --- /dev/null +++ b/doc/guides/cryptodevs/caam_jr.rst @@ -0,0 +1,150 @@ +.. SPDX-License-Identifier: BSD-3-Clause + Copyright 2018 NXP + + +NXP CAAM JOB RING (caam_jr) +=========================== + +The caam_jr PMD provides poll mode crypto driver support for NXP SEC 4.x+ (CAAM) +hardware accelerator. More information is available at: + +`NXP Cryptographic Acceleration Technology <https://www.nxp.com/applications/solutions/internet-of-things/secure-things/network-security-technology/cryptographic-acceleration-technology:NETWORK_SECURITY_CRYPTOG>`_. + +Architecture +------------ + +SEC is the SOC's security engine, which serves as NXP's latest cryptographic +acceleration and offloading hardware. It combines functions previously +implemented in separate modules to create a modular and scalable acceleration +and assurance engine. It also implements block encryption algorithms, stream +cipher algorithms, hashing algorithms, public key algorithms, run-time +integrity checking, and a hardware random number generator. SEC performs +higher-level cryptographic operations than previous NXP cryptographic +accelerators. This provides significant improvement to system level performance. + +SEC HW accelerator above 4.x+ version are also known as CAAM. + +caam_jr PMD is one of DPAA drivers which uses uio interface to interact with +Linux kernel for configure and destroy the device instance (ring). + + +Implementation +-------------- + +SEC provides platform assurance by working with SecMon, which is a companion +logic block that tracks the security state of the SOC. SEC is programmed by +means of descriptors (not to be confused with frame descriptors (FDs)) that +indicate the operations to be performed and link to the message and +associated data. SEC incorporates two DMA engines to fetch the descriptors, +read the message data, and write the results of the operations. The DMA +engine provides a scatter/gather capability so that SEC can read and write +data scattered in memory. SEC may be configured by means of software for +dynamic changes in byte ordering. The default configuration for this version +of SEC is little-endian mode. + +Note that one physical Job Ring represent one caam_jr device. + +Features +-------- + +The CAAM_JR PMD has support for: + +Cipher algorithms: + +* ``RTE_CRYPTO_CIPHER_3DES_CBC`` +* ``RTE_CRYPTO_CIPHER_AES128_CBC`` +* ``RTE_CRYPTO_CIPHER_AES192_CBC`` +* ``RTE_CRYPTO_CIPHER_AES256_CBC`` +* ``RTE_CRYPTO_CIPHER_AES128_CTR`` +* ``RTE_CRYPTO_CIPHER_AES192_CTR`` +* ``RTE_CRYPTO_CIPHER_AES256_CTR`` + +Hash algorithms: + +* ``RTE_CRYPTO_AUTH_SHA1_HMAC`` +* ``RTE_CRYPTO_AUTH_SHA224_HMAC`` +* ``RTE_CRYPTO_AUTH_SHA256_HMAC`` +* ``RTE_CRYPTO_AUTH_SHA384_HMAC`` +* ``RTE_CRYPTO_AUTH_SHA512_HMAC`` +* ``RTE_CRYPTO_AUTH_MD5_HMAC`` + +AEAD algorithms: + +* ``RTE_CRYPTO_AEAD_AES_GCM`` + +Supported DPAA SoCs +-------------------- + +* LS1046A/LS1026A +* LS1043A/LS1023A +* LS1028A +* LS1012A + +Limitations +----------- + +* Hash followed by Cipher mode is not supported +* Only supports the session-oriented API implementation (session-less APIs are not supported). + +Prerequisites +------------- + +caam_jr driver has following dependencies are not part of DPDK and must be installed separately: + +* **NXP Linux SDK** + + NXP Linux software development kit (SDK) includes support for the family + of QorIQ® ARM-Architecture-based system on chip (SoC) processors + and corresponding boards. + + It includes the Linux board support packages (BSPs) for NXP SoCs, + a fully operational tool chain, kernel and board specific modules. + + SDK and related information can be obtained from: `NXP QorIQ SDK <http://www.nxp.com/products/software-and-tools/run-time-software/linux-sdk/linux-sdk-for-qoriq-processors:SDKLINUX>`_. + +Currently supported by DPDK: + +* NXP SDK **18.09+**. +* Supported architectures: **arm64 LE**. + +* Follow the DPDK :ref:`Getting Started Guide for Linux <linux_gsg>` to setup the basic DPDK environment. + +Pre-Installation Configuration +------------------------------ + +Config File Options +~~~~~~~~~~~~~~~~~~~ + +The following options can be modified in the ``config`` file +to enable caam_jr PMD. + +Please note that enabling debugging options may affect system performance. + +* ``CONFIG_RTE_LIBRTE_PMD_CAAM_JR`` (default ``n``) + By default it is only enabled in common_linuxapp config. + Toggle compilation of the ``librte_pmd_caam_jr`` driver. + +* ``CONFIG_RTE_LIBRTE_PMD_CAAM_JR_BE`` (default ``n``) + By default it is disabled. + It can be used when the underlying hardware supports the CAAM in BE mode. + e.g. LS1043A, LS1046A supports CAAM in BE mode. + BE mode is enabled by default in defconfig-arm64-dpaa-linuxapp-gcc. + +Installations +------------- +To compile the caam_jr PMD for Linux arm64 gcc target, run the +following ``make`` command: + +.. code-block:: console + + cd <DPDK-source-directory> + make config T=arm64-armv8a-linuxapp-gcc install + +Enabling logs +------------- + +For enabling logs, use the following EAL parameter: + +.. code-block:: console + + ./your_crypto_application <EAL args> --log-level=pmd.crypto.caam,<level> diff --git a/doc/guides/cryptodevs/features/caam_jr.ini b/doc/guides/cryptodevs/features/caam_jr.ini new file mode 100644 index 00000000..68f8d819 --- /dev/null +++ b/doc/guides/cryptodevs/features/caam_jr.ini @@ -0,0 +1,46 @@ +; +; Supported features of the 'caam_jr' crypto driver. +; +; Refer to default.ini for the full list of available PMD features. +; +[Features] +Symmetric crypto = Y +Sym operation chaining = Y +HW Accelerated = Y +Protocol offload = Y +In Place SGL = Y +OOP SGL In SGL Out = Y +OOP SGL In LB Out = Y +OOP LB In SGL Out = Y +OOP LB In LB Out = Y + +; +; Supported crypto algorithms of the 'dpaa2_sec' crypto driver. +; +[Cipher] +AES CBC (128) = Y +AES CBC (192) = Y +AES CBC (256) = Y +AES CTR (128) = Y +AES CTR (192) = Y +AES CTR (256) = Y +3DES CBC = Y + +; +; Supported authentication algorithms of the 'dpaa2_sec' crypto driver. +; +[Auth] +MD5 HMAC = Y +SHA1 HMAC = Y +SHA224 HMAC = Y +SHA256 HMAC = Y +SHA384 HMAC = Y +SHA512 HMAC = Y + +; +; Supported AEAD algorithms of the 'dpaa2_sec' crypto driver. +; +[AEAD] +AES GCM (128) = Y +AES GCM (192) = Y +AES GCM (256) = Y diff --git a/doc/guides/cryptodevs/features/default.ini b/doc/guides/cryptodevs/features/default.ini index 92a7ccf3..810da0d7 100644 --- a/doc/guides/cryptodevs/features/default.ini +++ b/doc/guides/cryptodevs/features/default.ini @@ -38,9 +38,13 @@ AES ECB (256) = AES CTR (128) = AES CTR (192) = AES CTR (256) = +AES XTS (128) = +AES XTS (192) = +AES XTS (256) = AES DOCSIS BPI = 3DES CBC = 3DES CTR = +3DES ECB = DES CBC = DES DOCSIS BPI = SNOW3G UEA2 = diff --git a/doc/guides/cryptodevs/features/mvsam.ini b/doc/guides/cryptodevs/features/mvsam.ini index b7c105af..0cc90a53 100644 --- a/doc/guides/cryptodevs/features/mvsam.ini +++ b/doc/guides/cryptodevs/features/mvsam.ini @@ -5,17 +5,24 @@ [Features] Symmetric crypto = Y Sym operation chaining = Y +HW Accelerated = Y +OOP SGL In LB Out = Y +OOP LB In LB Out = Y ; ; Supported crypto algorithms of a default crypto driver. ; [Cipher] +NULL = Y AES CBC (128) = Y AES CBC (192) = Y AES CBC (256) = Y AES CTR (128) = Y AES CTR (192) = Y AES CTR (256) = Y +AES ECB (128) = Y +AES ECB (192) = Y +AES ECB (256) = Y 3DES CBC = Y 3DES CTR = Y @@ -23,10 +30,13 @@ AES CTR (256) = Y ; Supported authentication algorithms of a default crypto driver. ; [Auth] +NULL = Y MD5 = Y MD5 HMAC = Y SHA1 = Y SHA1 HMAC = Y +SHA224 = Y +SHA224 HMAC = Y SHA256 = Y SHA256 HMAC = Y SHA384 = Y @@ -40,3 +50,5 @@ AES GMAC = Y ; [AEAD] AES GCM (128) = Y +AES GCM (192) = Y +AES GCM (256) = Y diff --git a/doc/guides/cryptodevs/features/octeontx.ini b/doc/guides/cryptodevs/features/octeontx.ini new file mode 100644 index 00000000..307ab88c --- /dev/null +++ b/doc/guides/cryptodevs/features/octeontx.ini @@ -0,0 +1,62 @@ +; +; Supported features of the 'octeontx' crypto driver. +; +; Refer to default.ini for the full list of available PMD features. +; +[Features] +Symmetric crypto = Y +Sym operation chaining = Y +HW Accelerated = Y +In Place SGL = Y +OOP SGL In LB Out = Y +OOP SGL In SGL Out = Y + +; +; Supported crypto algorithms of 'octeontx' crypto driver. +; +[Cipher] +NULL = Y +3DES CBC = Y +3DES ECB = Y +AES CBC (128) = Y +AES CBC (192) = Y +AES CBC (256) = Y +AES CTR (128) = Y +AES CTR (192) = Y +AES CTR (256) = Y +AES XTS (128) = Y +AES XTS (256) = Y +DES CBC = Y +KASUMI F8 = Y +SNOW3G UEA2 = Y +ZUC EEA3 = Y + +; +; Supported authentication algorithms of 'octeontx' crypto driver. +; +[Auth] +NULL = Y +AES GMAC = Y +KASUMI F9 = Y +MD5 = Y +MD5 HMAC = Y +SHA1 = Y +SHA1 HMAC = Y +SHA224 = Y +SHA224 HMAC = Y +SHA256 = Y +SHA256 HMAC = Y +SHA384 = Y +SHA384 HMAC = Y +SHA512 = Y +SHA512 HMAC = Y +SNOW3G UIA2 = Y +ZUC EIA3 = Y + +; +; Supported AEAD algorithms of 'octeontx' crypto driver. +; +[AEAD] +AES GCM (128) = Y +AES GCM (192) = Y +AES GCM (256) = Y diff --git a/doc/guides/cryptodevs/features/qat.ini b/doc/guides/cryptodevs/features/qat.ini index 29d865e0..4f15ee0e 100644 --- a/doc/guides/cryptodevs/features/qat.ini +++ b/doc/guides/cryptodevs/features/qat.ini @@ -48,6 +48,7 @@ SNOW3G UIA2 = Y KASUMI F9 = Y AES XCBC MAC = Y ZUC EIA3 = Y +AES CMAC (128) = Y ; ; Supported AEAD algorithms of the 'qat' crypto driver. @@ -56,3 +57,6 @@ ZUC EIA3 = Y AES GCM (128) = Y AES GCM (192) = Y AES GCM (256) = Y +AES CCM (128) = Y +AES CCM (192) = Y +AES CCM (256) = Y diff --git a/doc/guides/cryptodevs/index.rst b/doc/guides/cryptodevs/index.rst index e9928a4e..83610e64 100644 --- a/doc/guides/cryptodevs/index.rst +++ b/doc/guides/cryptodevs/index.rst @@ -13,10 +13,12 @@ Crypto Device Drivers aesni_mb aesni_gcm armv8 + caam_jr ccp dpaa2_sec dpaa_sec kasumi + octeontx openssl mvsam null diff --git a/doc/guides/cryptodevs/mvsam.rst b/doc/guides/cryptodevs/mvsam.rst index fd418c26..7acae19b 100644 --- a/doc/guides/cryptodevs/mvsam.rst +++ b/doc/guides/cryptodevs/mvsam.rst @@ -37,32 +37,50 @@ support by utilizing MUSDK library, which provides cryptographic operations acceleration by using Security Acceleration Engine (EIP197) directly from user-space with minimum overhead and high performance. +Detailed information about SoCs that use MVSAM crypto driver can be obtained here: + +* https://www.marvell.com/embedded-processors/armada-70xx/ +* https://www.marvell.com/embedded-processors/armada-80xx/ +* https://www.marvell.com/embedded-processors/armada-3700/ + + Features -------- MVSAM CRYPTO PMD has support for: -* Symmetric crypto -* Sym operation chaining -* AES CBC (128) -* AES CBC (192) -* AES CBC (256) -* AES CTR (128) -* AES CTR (192) -* AES CTR (256) -* 3DES CBC -* 3DES CTR -* MD5 -* MD5 HMAC -* SHA1 -* SHA1 HMAC -* SHA256 -* SHA256 HMAC -* SHA384 -* SHA384 HMAC -* SHA512 -* SHA512 HMAC -* AES GCM (128) +Cipher algorithms: + +* ``RTE_CRYPTO_CIPHER_NULL`` +* ``RTE_CRYPTO_CIPHER_AES_CBC`` +* ``RTE_CRYPTO_CIPHER_AES_CTR`` +* ``RTE_CRYPTO_CIPHER_AES_ECB`` +* ``RTE_CRYPTO_CIPHER_3DES_CBC`` +* ``RTE_CRYPTO_CIPHER_3DES_CTR`` +* ``RTE_CRYPTO_CIPHER_3DES_ECB`` + +Hash algorithms: + +* ``RTE_CRYPTO_AUTH_NULL`` +* ``RTE_CRYPTO_AUTH_MD5`` +* ``RTE_CRYPTO_AUTH_MD5_HMAC`` +* ``RTE_CRYPTO_AUTH_SHA1`` +* ``RTE_CRYPTO_AUTH_SHA1_HMAC`` +* ``RTE_CRYPTO_AUTH_SHA224`` +* ``RTE_CRYPTO_AUTH_SHA224_HMAC`` +* ``RTE_CRYPTO_AUTH_SHA256`` +* ``RTE_CRYPTO_AUTH_SHA256_HMAC`` +* ``RTE_CRYPTO_AUTH_SHA384`` +* ``RTE_CRYPTO_AUTH_SHA384_HMAC`` +* ``RTE_CRYPTO_AUTH_SHA512`` +* ``RTE_CRYPTO_AUTH_SHA512_HMAC`` +* ``RTE_CRYPTO_AUTH_AES_GMAC`` + +AEAD algorithms: + +* ``RTE_CRYPTO_AEAD_AES_GCM`` + +For supported feature flags please consult :doc:`overview`. Limitations ----------- @@ -77,25 +95,18 @@ MVSAM CRYPTO PMD driver compilation is disabled by default due to external depen Currently there are two driver specific compilation options in ``config/common_base`` available: -- ``CONFIG_RTE_LIBRTE_MVSAM_CRYPTO`` (default ``n``) +- ``CONFIG_RTE_LIBRTE_PMD_MVSAM_CRYPTO`` (default: ``n``) Toggle compilation of the librte_pmd_mvsam driver. -- ``CONFIG_RTE_LIBRTE_MVSAM_CRYPTO_DEBUG`` (default ``n``) - - Toggle display of debugging messages. - -For a list of prerequisites please refer to `Prerequisites` section in -:ref:`MVPP2 Poll Mode Driver <mvpp2_poll_mode_driver>` guide. - MVSAM CRYPTO PMD requires MUSDK built with EIP197 support thus following extra option must be passed to the library configuration script: .. code-block:: console - --enable-sam + --enable-sam [--enable-sam-statistics] [--enable-sam-debug] -For `crypto_safexcel.ko` module build instructions please refer +For instructions how to build required kernel modules please refer to `doc/musdk_get_started.txt`. Initialization @@ -106,17 +117,15 @@ loaded: .. code-block:: console - insmod musdk_uio.ko - insmod mvpp2x_sysfs.ko - insmod mv_pp_uio.ko + insmod musdk_cma.ko + insmod crypto_safexcel.ko rings=0,0 insmod mv_sam_uio.ko - insmod crypto_safexcel.ko The following parameters (all optional) are exported by the driver: -* max_nb_queue_pairs: maximum number of queue pairs in the device (8 by default). -* max_nb_sessions: maximum number of sessions that can be created (2048 by default). -* socket_id: socket on which to allocate the device resources on. +- ``max_nb_queue_pairs``: maximum number of queue pairs in the device (default: 8 - A8K, 4 - A7K/A3K). +- ``max_nb_sessions``: maximum number of sessions that can be created (default: 2048). +- ``socket_id``: socket on which to allocate the device resources on. l2fwd-crypto example application can be used to verify MVSAM CRYPTO PMD operation: @@ -129,65 +138,3 @@ operation: --auth_op GENERATE --auth_algo sha1-hmac \ --auth_key 10:11:12:13:14:15:16:17:18:19:1a:1b:1c:1d:1e:1f -Example output: - -.. code-block:: console - - [...] - AAD: at [0x7f253ceb80], len= - P ID 0 configuration ---- - Port mode : KR - MAC status : disabled - Link status : link up - Port speed : 10G - Port duplex : full - Port: Egress enable tx_port_num=16 qmap=0x1 - PORT: Port0 - link - P ID 0 configuration ---- - Port mode : KR - MAC status : disabled - Link status : link down - Port speed : 10G - Port duplex : full - Port: Egress enable tx_port_num=16 qmap=0x1 - Port 0, MAC address: 00:50:43:02:21:20 - - - Checking link statusdone - Port 0 Link Up - speed 0 Mbps - full-duplex - Lcore 0: RX port 0 - Allocated session pool on socket 0 - eip197: 0:0 registers: paddr: 0xf2880000, vaddr: 0x0x7f56a80000 - DMA buffer (131136 bytes) for CDR #0 allocated: paddr = 0xb0585e00, vaddr = 0x7f09384e00 - DMA buffer (131136 bytes) for RDR #0 allocated: paddr = 0xb05a5f00, vaddr = 0x7f093a4f00 - DMA buffers allocated for 2049 operations. Tokens - 256 bytes - Lcore 0: cryptodev 0 - L2FWD: lcore 1 has nothing to do - L2FWD: lcore 2 has nothing to do - L2FWD: lcore 3 has nothing to do - L2FWD: entering main loop on lcore 0 - L2FWD: -- lcoreid=0 portid=0 - L2FWD: -- lcoreid=0 cryptoid=0 - Options:- - nportmask: ffffffff - ports per lcore: 1 - refresh period : 10000 - single lcore mode: disabled - stats_printing: enabled - sessionless crypto: disabled - - Crypto chain: Input --> Encrypt --> Auth generate --> Output - - ---- Cipher information --- - Algorithm: aes-cbc - Cipher key: at [0x7f56db4e80], len=16 - 00000000: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F | ................ - IV: at [0x7f56db4b80], len=16 - 00000000: 20 F0 63 0E 45 EB 2D 84 72 D4 13 6E 36 B5 AF FE | .c.E.-.r..n6... - - ---- Authentication information --- - Algorithm: sha1-hmac - Auth key: at [0x7f56db4d80], len=16 - 00000000: 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F | ................ - IV: at [0x7f56db4a80], len=0 - AAD: at [0x7f253ceb80], len= diff --git a/doc/guides/cryptodevs/octeontx.rst b/doc/guides/cryptodevs/octeontx.rst new file mode 100644 index 00000000..660e980c --- /dev/null +++ b/doc/guides/cryptodevs/octeontx.rst @@ -0,0 +1,127 @@ +.. SPDX-License-Identifier: BSD-3-Clause + Copyright(c) 2018 Cavium, Inc + +Cavium OCTEON TX Crypto Poll Mode Driver +======================================== + +The OCTEON TX crypto poll mode driver provides support for offloading +cryptographic operations to cryptographic accelerator units on +**OCTEON TX** :sup:`®` family of processors (CN8XXX). The OCTEON TX crypto +poll mode driver enqueues the crypto request to this accelerator and dequeues +the response once the operation is completed. + +Supported Algorithms +-------------------- + +Cipher Algorithms +~~~~~~~~~~~~~~~~~ + +* ``RTE_CRYPTO_CIPHER_NULL`` +* ``RTE_CRYPTO_CIPHER_3DES_CBC`` +* ``RTE_CRYPTO_CIPHER_3DES_ECB`` +* ``RTE_CRYPTO_CIPHER_AES_CBC`` +* ``RTE_CRYPTO_CIPHER_AES_CTR`` +* ``RTE_CRYPTO_CIPHER_AES_XTS`` +* ``RTE_CRYPTO_CIPHER_DES_CBC`` +* ``RTE_CRYPTO_CIPHER_KASUMI_F8`` +* ``RTE_CRYPTO_CIPHER_SNOW3G_UEA2`` +* ``RTE_CRYPTO_CIPHER_ZUC_EEA3`` + +Hash Algorithms +~~~~~~~~~~~~~~~ + +* ``RTE_CRYPTO_AUTH_NULL`` +* ``RTE_CRYPTO_AUTH_AES_GMAC`` +* ``RTE_CRYPTO_AUTH_KASUMI_F9`` +* ``RTE_CRYPTO_AUTH_MD5`` +* ``RTE_CRYPTO_AUTH_MD5_HMAC`` +* ``RTE_CRYPTO_AUTH_SHA1`` +* ``RTE_CRYPTO_AUTH_SHA1_HMAC`` +* ``RTE_CRYPTO_AUTH_SHA224`` +* ``RTE_CRYPTO_AUTH_SHA224_HMAC`` +* ``RTE_CRYPTO_AUTH_SHA256`` +* ``RTE_CRYPTO_AUTH_SHA256_HMAC`` +* ``RTE_CRYPTO_AUTH_SHA384`` +* ``RTE_CRYPTO_AUTH_SHA384_HMAC`` +* ``RTE_CRYPTO_AUTH_SHA512`` +* ``RTE_CRYPTO_AUTH_SHA512_HMAC`` +* ``RTE_CRYPTO_AUTH_SNOW3G_UIA2`` +* ``RTE_CRYPTO_AUTH_ZUC_EIA3`` + +AEAD Algorithms +~~~~~~~~~~~~~~~ + +* ``RTE_CRYPTO_AEAD_AES_GCM`` + +Compilation +----------- + +The **OCTEON TX** :sup:`®` board must be running the linux kernel based on +sdk-6.2.0 patch 3. In this, the OCTEON TX crypto PF driver is already built in. + +For compiling the OCTEON TX crypto poll mode driver, please check if the +CONFIG_RTE_LIBRTE_PMD_OCTEONTX_CRYPTO setting is set to `y` in +config/common_base file. + +* ``CONFIG_RTE_LIBRTE_PMD_OCTEONTX_CRYPTO=y`` + +The following are the steps to compile the OCTEON TX crypto poll mode driver: + +.. code-block:: console + + cd <dpdk directory> + make config T=arm64-thunderx-linuxapp-gcc + make + +The example applications can be compiled using the following: + +.. code-block:: console + + cd <dpdk directory> + export RTE_SDK=$PWD + export RTE_TARGET=build + cd examples/<application> + make + +Execution +--------- + +The number of crypto VFs to be enabled can be controlled by setting sysfs entry, +`sriov_numvfs`, for the corresponding PF driver. + +.. code-block:: console + + echo <num_vfs> > /sys/bus/pci/devices/<dev_bus_id>/sriov_numvfs + +The device bus ID, `dev_bus_id`, to be used in the above step can be found out +by using dpdk-devbind.py script. The OCTEON TX crypto PF device need to be +identified and the corresponding device number can be used to tune various PF +properties. + + +Once the required VFs are enabled, dpdk-devbind.py script can be used to +identify the VFs. To be accessible from DPDK, VFs need to be bound to vfio-pci +driver: + +.. code-block:: console + + cd <dpdk directory> + ./usertools/dpdk-devbind.py -u <vf device no> + ./usertools/dpdk-devbind.py -b vfio-pci <vf device no> + +Appropriate huge page need to be setup in order to run the DPDK example +applications. + +.. code-block:: console + + echo 8 > /sys/kernel/mm/hugepages/hugepages-524288kB/nr_hugepages + mkdir /mnt/huge + mount -t hugetlbfs nodev /mnt/huge + +Example applications can now be executed with crypto operations offloaded to +OCTEON TX crypto PMD. + +.. code-block:: console + + ./build/ipsec-secgw --log-level=8 -c 0xff -- -P -p 0x3 -u 0x2 --config + "(1,0,0),(0,0,0)" -f ep1.cfg diff --git a/doc/guides/cryptodevs/overview.rst b/doc/guides/cryptodevs/overview.rst index 3f776f07..607e758d 100644 --- a/doc/guides/cryptodevs/overview.rst +++ b/doc/guides/cryptodevs/overview.rst @@ -33,7 +33,7 @@ Supported Feature Flags scatter-gathered styled buffers. - "OOP LB In LB Out" feature flag stands for - "Out-of-place Linear Buffers Input, Scatter-gather list Output", + "Out-of-place Linear Buffers Input, Linear Buffers Output", which means that Out-of-place operation is supported, with linear input and output buffers. diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst index bdc58eb2..b2dfeb00 100644 --- a/doc/guides/cryptodevs/qat.rst +++ b/doc/guides/cryptodevs/qat.rst @@ -4,17 +4,30 @@ Intel(R) QuickAssist (QAT) Crypto Poll Mode Driver ================================================== -The QAT PMD provides poll mode crypto driver support for the following +QAT documentation consists of three parts: + +* Details of the symmetric crypto service below. +* Details of the `compression service <http://dpdk.org/doc/guides/compressdevs/qat_comp.html>`_ + in the compressdev drivers section. +* Details of building the common QAT infrastructure and the PMDs to support the + above services. See :ref:`building_qat` below. + + +Symmetric Crypto Service on QAT +------------------------------- + +The QAT crypto PMD provides poll mode crypto driver support for the following hardware accelerator devices: * ``Intel QuickAssist Technology DH895xCC`` * ``Intel QuickAssist Technology C62x`` * ``Intel QuickAssist Technology C3xxx`` * ``Intel QuickAssist Technology D15xx`` +* ``Intel QuickAssist Technology C4xxx`` Features --------- +~~~~~~~~ The QAT PMD has support for: @@ -50,14 +63,16 @@ Hash algorithms: * ``RTE_CRYPTO_AUTH_KASUMI_F9`` * ``RTE_CRYPTO_AUTH_AES_GMAC`` * ``RTE_CRYPTO_AUTH_ZUC_EIA3`` +* ``RTE_CRYPTO_AUTH_AES_CMAC`` Supported AEAD algorithms: * ``RTE_CRYPTO_AEAD_AES_GCM`` +* ``RTE_CRYPTO_AEAD_AES_CCM`` Limitations ------------ +~~~~~~~~~~~ * Only supports the session-oriented API implementation (session-less APIs are not supported). * SNOW 3G (UEA2), KASUMI (F8) and ZUC (EEA3) supported only if cipher length and offset fields are byte-multiple. @@ -69,104 +84,155 @@ Limitations Extra notes on KASUMI F9 ------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~ When using KASUMI F9 authentication algorithm, the input buffer must be -constructed according to the 3GPP KASUMI specifications (section 4.4, page 13): -`<http://cryptome.org/3gpp/35201-900.pdf>`_. -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. +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 +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) +Also, offset of data to authenticate "op.sym.auth.data.offset" must be such that points at the start of the COUNT bytes. -Building the DPDK QAT cryptodev PMD ------------------------------------ +.. _building_qat: + +Building PMDs on QAT +-------------------- + +A QAT device can host multiple acceleration services: + +* symmetric cryptography +* data compression -To enable QAT crypto in DPDK, follow the instructions for modifying the compile-time -configuration file as described `here <http://dpdk.org/doc/guides/linux_gsg/build_dpdk.html>`_. +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. -Quick instructions are as follows: +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 config T=x86_64-native-linuxapp-gcc - sed -i 's,\(CONFIG_RTE_LIBRTE_PMD_QAT\)=n,\1=y,' build/.config + 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: -.. _qat_kernel_installation: +.. code-block:: console -Dependency on the QAT kernel driver ------------------------------------ + cd to the top-level DPDK directory + make defconfig + make -To use the QAT PMD an SRIOV-enabled QAT kernel driver is required. The VF -devices created and initialised by this driver will be used by the QAT PMD. -Instructions for installation are below, but first an explanation of the -relationships between the PF/VF devices and the PMDs visible to -DPDK applications. +Build Configuration +~~~~~~~~~~~~~~~~~~~ +These are the build configuration options affecting QAT, and their default values: -Acceleration services - cryptography and compression - are provided to DPDK -applications via PMDs which register to implement the corresponding -cryptodev and compressdev APIs. +.. code-block:: console -Each QuickAssist VF device can expose one cryptodev PMD and/or one compressdev PMD. -These QAT PMDs share the same underlying device and pci-mgmt code, but are -enumerated independently on their respective APIs and appear as independent -devices to applications. + 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 -.. Note:: +CONFIG_RTE_LIBRTE_PMD_QAT must be enabled for any QAT PMD to be built. - Each VF can only be used by one DPDK process. It is not possible to share - the same VF across multiple processes, even if these processes are using - different acceleration services. +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. - Conversely one DPDK process can use one or more QAT VFs and can expose both - cryptodev and compressdev instances on each of those VFs. +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 is a separate config item for max cryptodevs CONFIG_RTE_CRYPTO_MAX_DEVS, +if necessary this 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. Device and driver naming ------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~ * The qat cryptodev driver name is "crypto_qat". - The rte_cryptodev_devices_get() returns the devices exposed by this driver. + 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. + "<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 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 "comp_qat". +* 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. + +Each QuickAssist PF device exposes a number of VF devices. Each VF device can +enable one cryptodev PMD and/or one compressdev PMD. +These QAT PMDs share the same underlying device and pci-mgmt code, but are +enumerated independently on their respective APIs and appear as independent +devices to applications. + +.. Note:: + + Each VF can only be used by one DPDK process. It is not possible to share + the same VF across multiple processes, even if these processes are using + different acceleration services. + + Conversely one DPDK process can use one or more QAT VFs and can expose both + cryptodev and compressdev instances on each of those VFs. + Available kernel drivers ------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~ Kernel drivers for each device are listed in the following table. Scroll right -to check that the driver and device supports the servic you require. +to check that the driver and device supports the service you require. .. _table_qat_pmds_drivers: @@ -190,6 +256,8 @@ to check that the driver and device supports the servic you require. +-----+----------+---------------+---------------+------------+--------+------+--------+--------+-----------+-------------+ | 2 | D15xx | p | qat_d15xx | d15xx | 6f54 | 1 | 6f55 | 16 | Yes | No | +-----+----------+---------------+---------------+------------+--------+------+--------+--------+-----------+-------------+ + | 3 | C4xxx | p | qat_c4xxx | c4xxx | 18a0 | 1 | 18a1 | 128 | Yes | No | + +-----+----------+---------------+---------------+------------+--------+------+--------+--------+-----------+-------------+ The ``Driver`` column indicates either the Linux kernel version in which @@ -203,7 +271,7 @@ If you are running on a kernel which includes a driver for your device, see Installation using kernel.org driver ------------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The examples below are based on the C62x device, if you have a different device use the corresponding values in the above table. @@ -274,7 +342,7 @@ To complete the installation follow the instructions in Installation using 01.org QAT driver ------------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Download the latest QuickAssist Technology Driver from `01.org <https://01.org/packet-processing/intel%C2%AE-quickassist-technology-drivers-and-patches>`_. @@ -368,12 +436,12 @@ To complete the installation - follow instructions in `Binding the available VFs Binding the available VFs to the DPDK UIO driver ------------------------------------------------- +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Unbind the VFs from the stock driver so they can be bound to the uio driver. For an Intel(R) QuickAssist Technology DH895xCC device -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The unbind command below assumes ``BDFs`` of ``03:01.00-03:04.07``, if your VFs are different adjust the unbind command below:: @@ -386,7 +454,7 @@ VFs are different adjust the unbind command below:: done For an Intel(R) QuickAssist Technology C62x device -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The unbind command below assumes ``BDFs`` of ``1a:01.00-1a:02.07``, ``3d:01.00-3d:02.07`` and ``3f:01.00-3f:02.07``, if your VFs are different @@ -406,7 +474,7 @@ adjust the unbind command below:: done For Intel(R) QuickAssist Technology C3xxx or D15xx device -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The unbind command below assumes ``BDFs`` of ``01:01.00-01:02.07``, if your VFs are different adjust the unbind command below:: @@ -419,7 +487,7 @@ VFs are different adjust the unbind command below:: done Bind to the DPDK uio driver -~~~~~~~~~~~~~~~~~~~~~~~~~~~ +^^^^^^^^^^^^^^^^^^^^^^^^^^^ Install the DPDK igb_uio driver, bind the VF PCI Device id to it and use lspci to confirm the VF devices are now in use by igb_uio kernel driver, @@ -438,9 +506,29 @@ Another way to bind the VFs to the DPDK UIO driver is by using the cd to the top-level DPDK directory ./usertools/dpdk-devbind.py -b igb_uio 0000:03:01.1 +Testing +~~~~~~~ + +QAT crypto PMD can be tested by running the test application:: + + make defconfig + make test-build -j + cd ./build/app + ./test -l1 -n1 -w <your qat bdf> + RTE>>cryptodev_qat_autotest + +QAT compression PMD can be tested by running the test application:: + + make defconfig + sed -i 's,\(CONFIG_RTE_COMPRESSDEV_TEST\)=n,\1=y,' build/.config + make test-build -j + cd ./build/app + ./test -l1 -n1 -w <your qat bdf> + RTE>>compressdev_autotest + Debugging ----------------------------------------- +~~~~~~~~~ There are 2 sets of trace available via the dynamic logging feature: diff --git a/doc/guides/eventdevs/dpaa.rst b/doc/guides/eventdevs/dpaa.rst index 73832957..2f356d3c 100644 --- a/doc/guides/eventdevs/dpaa.rst +++ b/doc/guides/eventdevs/dpaa.rst @@ -122,6 +122,8 @@ Example: ./your_eventdev_application --vdev="event_dpaa1" +* Use dev arg option ``disable_intr=1`` to disable the interrupt mode + Limitations ----------- diff --git a/doc/guides/eventdevs/dsw.rst b/doc/guides/eventdevs/dsw.rst new file mode 100644 index 00000000..6653f501 --- /dev/null +++ b/doc/guides/eventdevs/dsw.rst @@ -0,0 +1,96 @@ +.. SPDX-License-Identifier: BSD-3-Clause + Copyright(c) 2018 Ericsson AB + +Distributed Software Eventdev Poll Mode Driver +============================================== + +The distributed software event device is an eventdev driver which +distributes the task of scheduling events among all the eventdev ports +and the lcore threads using them. + +Features +-------- + +Queues + * Atomic + * Parallel + * Single-Link + +Ports + * Load balanced (for Atomic, Ordered, Parallel queues) + * Single Link (for single-link queues) + +Configuration and Options +------------------------- + +The distributed software eventdev is a vdev device, and as such can be +created from the application code, or from the EAL command line: + +* Call ``rte_vdev_init("event_dsw0")`` from the application + +* Use ``--vdev="event_dsw0"`` in the EAL options, which will call + rte_vdev_init() internally + +Example: + +.. code-block:: console + + ./your_eventdev_application --vdev="event_dsw0" + +Limitations +----------- + +Unattended Ports +~~~~~~~~~~~~~~~~ + +The distributed software eventdev uses an internal signaling schema +between the ports to achieve load balancing. In order for this to +work, the application must perform enqueue and/or dequeue operations +on all ports. + +Producer-only ports which currently have no events to enqueue should +periodically call rte_event_enqueue_burst() with a zero-sized burst. + +Ports left unattended for longer periods of time will prevent load +balancing, and also cause traffic interruptions on the flows which +are in the process of being migrated. + +Output Buffering +~~~~~~~~~~~~~~~~ + +For efficiency reasons, the distributed software eventdev might not +send enqueued events immediately to the destination port, but instead +store them in an internal buffer in the source port. + +In case no more events are enqueued on a port with buffered events, +these events will be sent after the application has performed a number +of enqueue and/or dequeue operations. + +For explicit flushing, an application may call +rte_event_enqueue_burst() with a zero-sized burst. + + +Priorities +~~~~~~~~~~ + +The distributed software eventdev does not support event priorities. + +Ordered Queues +~~~~~~~~~~~~~~ + +The distributed software eventdev does not support the ordered queue type. + + +"All Types" Queues +~~~~~~~~~~~~~~~~~~ + +The distributed software eventdev does not support queues of type +RTE_EVENT_QUEUE_CFG_ALL_TYPES, which allow both atomic, ordered, and +parallel events on the same queue. + +Dynamic Link/Unlink +~~~~~~~~~~~~~~~~~~~ + +The distributed software eventdev does not support calls to +rte_event_port_link() or rte_event_port_unlink() after +rte_event_dev_start() has been called. diff --git a/doc/guides/eventdevs/index.rst b/doc/guides/eventdevs/index.rst index 18ec8e46..f7382dc8 100644 --- a/doc/guides/eventdevs/index.rst +++ b/doc/guides/eventdevs/index.rst @@ -13,6 +13,7 @@ application trough the eventdev API. dpaa dpaa2 + dsw sw octeontx opdl diff --git a/doc/guides/eventdevs/octeontx.rst b/doc/guides/eventdevs/octeontx.rst index 18cfc7a9..e276fd44 100644 --- a/doc/guides/eventdevs/octeontx.rst +++ b/doc/guides/eventdevs/octeontx.rst @@ -1,11 +1,11 @@ .. SPDX-License-Identifier: BSD-3-Clause Copyright(c) 2017 Cavium, Inc -OCTEONTX SSOVF Eventdev Driver -============================== +OCTEON TX SSOVF Eventdev Driver +=============================== -The OCTEONTX SSOVF PMD (**librte_pmd_octeontx_ssovf**) provides poll mode -eventdev driver support for the inbuilt event device found in the **Cavium OCTEONTX** +The OCTEON TX SSOVF PMD (**librte_pmd_octeontx_ssovf**) provides poll mode +eventdev driver support for the inbuilt event device found in the **Cavium OCTEON TX** SoC family as well as their virtual functions (VF) in SR-IOV context. More information can be found at `Cavium, Inc Official Website @@ -14,7 +14,7 @@ More information can be found at `Cavium, Inc Official Website Features -------- -Features of the OCTEONTX SSOVF PMD are: +Features of the OCTEON TX SSOVF PMD are: - 64 Event queues - 32 Event ports @@ -32,8 +32,8 @@ Features of the OCTEONTX SSOVF PMD are: time granularity of 1us. - Up to 64 event timer adapters. -Supported OCTEONTX SoCs ------------------------ +Supported OCTEON TX SoCs +------------------------ - CN83xx Prerequisites @@ -57,7 +57,7 @@ Please note that enabling debugging options may affect system performance. Driver Compilation ~~~~~~~~~~~~~~~~~~ -To compile the OCTEONTX SSOVF PMD for Linux arm64 gcc target, run the +To compile the OCTEON TX SSOVF PMD for Linux arm64 gcc target, run the following ``make`` command: .. code-block:: console @@ -69,7 +69,7 @@ following ``make`` command: Initialization -------------- -The octeontx eventdev is exposed as a vdev device which consists of a set +The OCTEON TX eventdev is exposed as a vdev device which consists of a set of SSO group and work-slot PCIe VF devices. On EAL initialization, SSO PCIe VF devices will be probed and then the vdev device can be created from the application code, or from the EAL command line based on @@ -90,7 +90,7 @@ Example: Selftest -------- -The functionality of octeontx eventdev can be verified using this option, +The functionality of OCTEON TX eventdev can be verified using this option, various unit and functional tests are run to verify the sanity. The tests are run once the vdev creation is successfully complete. diff --git a/doc/guides/eventdevs/opdl.rst b/doc/guides/eventdevs/opdl.rst index 21052232..0262a337 100644 --- a/doc/guides/eventdevs/opdl.rst +++ b/doc/guides/eventdevs/opdl.rst @@ -62,7 +62,7 @@ Queue Dependencies As stated the order in which packets travel through queues is static in nature. They go through the queues in the order the queues are setup at initialisation ``rte_event_queue_setup()``. For example if an application -sets up 3 queues, Q0, Q1, Q2 and has 3 assoicated ports P0, P1, P2 and +sets up 3 queues, Q0, Q1, Q2 and has 3 associated ports P0, P1, P2 and P3 then packets must be * Enqueued onto Q0 (typically through P0), then diff --git a/doc/guides/howto/index.rst b/doc/guides/howto/index.rst index e13a090c..a642a2be 100644 --- a/doc/guides/howto/index.rst +++ b/doc/guides/howto/index.rst @@ -17,3 +17,4 @@ HowTo Guides virtio_user_for_container_networking virtio_user_as_exceptional_path packet_capture_framework + telemetry diff --git a/doc/guides/howto/rte_flow.rst b/doc/guides/howto/rte_flow.rst index caa4e1af..6a8534d9 100644 --- a/doc/guides/howto/rte_flow.rst +++ b/doc/guides/howto/rte_flow.rst @@ -32,10 +32,10 @@ Code .. code-block:: c /* create the attribute structure */ - struct rte_flow_attr attr = {.ingress = 1}; + struct rte_flow_attr attr = { .ingress = 1 }; struct rte_flow_item pattern[MAX_PATTERN_IN_FLOW]; struct rte_flow_action actions[MAX_ACTIONS_IN_FLOW]; - struct rte_flow_item_etc eth; + struct rte_flow_item_eth eth; struct rte_flow_item_vlan vlan; struct rte_flow_item_ipv4 ipv4; struct rte_flow *flow; @@ -55,15 +55,15 @@ Code pattern[2].spec = &ipv4; /* end the pattern array */ - pattern[3].type = RTE_FLOW_ITEM)TYPE_END; + pattern[3].type = RTE_FLOW_ITEM_TYPE_END; /* create the drop action */ actions[0].type = RTE_FLOW_ACTION_TYPE_DROP; actions[1].type = RTE_FLOW_ACTION_TYPE_END; /* validate and create the flow rule */ - if (!rte_flow_validate(port_id, &attr, pattern, actions, &error) - flow = rte_flow_create(port_id, &attr, pattern, actions, &error) + if (!rte_flow_validate(port_id, &attr, pattern, actions, &error)) + flow = rte_flow_create(port_id, &attr, pattern, actions, &error); Output ~~~~~~ @@ -120,7 +120,7 @@ clarity):: tpmd> flow create 0 ingress pattern eth / vlan / ipv4 dst spec 192.168.3.0 dst mask 255.255.255.0 / - end actions drop / end + end actions drop / end Code ~~~~ @@ -130,7 +130,7 @@ Code struct rte_flow_attr attr = {.ingress = 1}; struct rte_flow_item pattern[MAX_PATTERN_IN_FLOW]; struct rte_flow_action actions[MAX_ACTIONS_IN_FLOW]; - struct rte_flow_item_etc eth; + struct rte_flow_item_eth eth; struct rte_flow_item_vlan vlan; struct rte_flow_item_ipv4 ipv4; struct rte_flow_item_ipv4 ipv4_mask; @@ -153,15 +153,15 @@ Code pattern[2].mask = &ipv4_mask; /* end the pattern array */ - pattern[3].type = RTE_FLOW_ITEM)TYPE_END; + pattern[3].type = RTE_FLOW_ITEM_TYPE_END; /* create the drop action */ actions[0].type = RTE_FLOW_ACTION_TYPE_DROP; actions[1].type = RTE_FLOW_ACTION_TYPE_END; /* validate and create the flow rule */ - if (!rte_flow_validate(port_id, &attr, pattern, actions, &error) - flow = rte_flow_create(port_id, &attr, pattern, actions, &error) + if (!rte_flow_validate(port_id, &attr, pattern, actions, &error)) + flow = rte_flow_create(port_id, &attr, pattern, actions, &error); Output ~~~~~~ @@ -227,10 +227,10 @@ Code .. code-block:: c - struct rte_flow_attr attr = {.ingress = 1}; + struct rte_flow_attr attr = { .ingress = 1 }; struct rte_flow_item pattern[MAX_PATTERN_IN_FLOW]; struct rte_flow_action actions[MAX_ACTIONS_IN_FLOW]; - struct rte_flow_item_etc eth; + struct rte_flow_item_eth eth; struct rte_flow_item_vlan vlan; struct rte_flow_action_queue queue = { .index = 3 }; struct rte_flow *flow; @@ -246,16 +246,16 @@ Code pattern[1].spec = &vlan; /* end the pattern array */ - pattern[2].type = RTE_FLOW_ITEM)TYPE_END; + pattern[2].type = RTE_FLOW_ITEM_TYPE_END; /* create the queue action */ actions[0].type = RTE_FLOW_ACTION_TYPE_QUEUE; - actions[0].conf = &queue + actions[0].conf = &queue; actions[1].type = RTE_FLOW_ACTION_TYPE_END; /* validate and create the flow rule */ - if (!rte_flow_validate(port_id, &attr, pattern, actions, &error) - flow = rte_flow_create(port_id, &attr, pattern, actions, &error) + if (!rte_flow_validate(port_id, &attr, pattern, actions, &error)) + flow = rte_flow_create(port_id, &attr, pattern, actions, &error); Output ~~~~~~ diff --git a/doc/guides/howto/telemetry.rst b/doc/guides/howto/telemetry.rst new file mode 100644 index 00000000..3fcb0619 --- /dev/null +++ b/doc/guides/howto/telemetry.rst @@ -0,0 +1,85 @@ +.. SPDX-License-Identifier: BSD-3-Clause + Copyright(c) 2018 Intel Corporation. + +DPDK Telemetry API User Guide +============================== + +This document describes how the Data Plane Development Kit(DPDK) Telemetry API +is used for querying port statistics from incoming traffic. + +Introduction +------------ + +The ``librte_telemetry`` provides the functionality so that users may query +metrics from incoming port traffic. The application which initializes packet +forwarding will act as the server, sending metrics to the requesting application +which acts as the client. + +In DPDK, applications are used to initialize the ``telemetry``. To view incoming +traffic on featured ports, the application should be run first (ie. after ports +are configured). Once the application is running, the service assurance agent +(for example the collectd plugin) should be run to begin querying the API. + +A client connects their Service Assurance application to the DPDK application +via a UNIX socket. Once a connection is established, a client can send JSON +messages to the DPDK application requesting metrics via another UNIX client. +This request is then handled and parsed if valid. The response is then +formatted in JSON and sent back to the requesting client. + +Pre-requisites +~~~~~~~~~~~~~~ + +* Python ≥ 2.5 + +* Jansson library for JSON serialization + +Test Environment +---------------- + +``telemetry`` offers a range of selftests that a client can run within +the DPDK application. + +Selftests are disabled by default. They can be enabled by setting the 'selftest' +variable to 1 in rte_telemetry_initial_accept(). + +Note: this 'hardcoded' value is temporary. + +Configuration +------------- + +Enable the telemetry API by modifying the following config option before +building DPDK:: + + CONFIG_RTE_LIBRTE_TELEMETRY=y + +Note: Meson will pick this up automatically if ``libjansson`` is available. + +Running the Application +----------------------- + +The following steps demonstrate how to run the ``telemetry`` API to query all +statistics on all active ports, using the ``telemetry_client`` python script +to query. +Note: This guide assumes packet generation is applicable and the user is +testing with testpmd as a DPDK primary application to forward packets, although +any DPDK application is applicable. + +#. Launch testpmd as the primary application with ``telemetry``.:: + + ./app/testpmd --telemetry + +#. Launch the ``telemetry`` python script with a client filepath.:: + + python usertools/telemetry_client.py /var/run/some_client + + The client filepath is going to be used to setup our UNIX connection with the + DPDK primary application, in this case ``testpmd`` + This will initialize a menu where a client can proceed to recursively query + statistics, request statistics once or unregister the file_path, thus exiting + the menu. + +#. Send traffic to any or all available ports from a traffic generator. + Select a query option(recursive or singular polling). + The metrics will then be displayed on the client terminal in JSON format. + +#. Once finished, unregister the client using the menu command. diff --git a/doc/guides/howto/virtio_user_as_exceptional_path.rst b/doc/guides/howto/virtio_user_as_exceptional_path.rst index 6a13c761..4910c12d 100644 --- a/doc/guides/howto/virtio_user_as_exceptional_path.rst +++ b/doc/guides/howto/virtio_user_as_exceptional_path.rst @@ -57,8 +57,8 @@ compiling the kernel and those kernel modules should be inserted. $(testpmd) -l 2-3 -n 4 \ --vdev=virtio_user0,path=/dev/vhost-net,queue_size=1024 \ - -- -i --txqflags=0x0 --enable-lro \ - --enable-rx-cksum --rxd=1024 --txd=1024 + -- -i --tx-offloads=0x0000002c --enable-lro \ + --txd=1024 --rxd=1024 This command runs testpmd with two ports, one physical NIC to communicate with outside, and one virtio-user to communicate with kernel. @@ -69,11 +69,6 @@ compiling the kernel and those kernel modules should be inserted. VIRTIO_NET_F_GUEST_TSO6 feature so that large packets from kernel can be transmitted to DPDK application and further TSOed by physical NIC. -* ``--enable-rx-cksum`` - - This is used to negotiate VIRTIO_NET_F_GUEST_CSUM so that packets from - kernel can be deemed as valid Rx checksumed. - * ``queue_size`` 256 by default. To avoid shortage of descriptors, we can increase it to 1024. @@ -86,9 +81,17 @@ compiling the kernel and those kernel modules should be inserted. $(testpmd) -l 2-3 -n 4 \ --vdev=virtio_user0,path=/dev/vhost-net,queues=2,queue_size=1024 \ - -- -i --txqflags=0x0 --enable-lro \ - --enable-rx-cksum --txq=2 --rxq=2 --rxd=1024 \ - --txd=1024 + -- -i --tx-offloads=0x0000002c --enable-lro \ + --txq=2 --rxq=2 --txd=1024 --rxd=1024 + +#. Enable Rx checksum offloads in testpmd: + + .. code-block:: console + + (testpmd) port stop 0 + (testpmd) port config 0 rx_offload tcp_cksum on + (testpmd) port config 0 rx_offload udp_cksum on + (testpmd) port start 0 #. Start testpmd: diff --git a/doc/guides/howto/virtio_user_for_container_networking.rst b/doc/guides/howto/virtio_user_for_container_networking.rst index 476ce3a6..2313dc79 100644 --- a/doc/guides/howto/virtio_user_for_container_networking.rst +++ b/doc/guides/howto/virtio_user_for_container_networking.rst @@ -96,7 +96,7 @@ some minor changes. dpdk-app-testpmd testpmd -l 6-7 -n 4 -m 1024 --no-pci \ --vdev=virtio_user0,path=/var/run/usvhost \ --file-prefix=container \ - -- -i --txqflags=0xf00 --disable-hw-vlan + -- -i Note: If we run all above setup on the host, it's a shm-based IPC. diff --git a/doc/guides/mempool/octeontx.rst b/doc/guides/mempool/octeontx.rst index b06bb610..e05aeb94 100644 --- a/doc/guides/mempool/octeontx.rst +++ b/doc/guides/mempool/octeontx.rst @@ -1,11 +1,11 @@ .. SPDX-License-Identifier: BSD-3-Clause Copyright(c) 2017 Cavium, Inc -OCTEONTX FPAVF Mempool Driver -============================= +OCTEON TX FPAVF Mempool Driver +============================== -The OCTEONTX FPAVF PMD (**librte_mempool_octeontx**) is a mempool -driver for offload mempool device found in **Cavium OCTEONTX** SoC +The OCTEON TX FPAVF PMD (**librte_mempool_octeontx**) is a mempool +driver for offload mempool device found in **Cavium OCTEON TX** SoC family. More information can be found at `Cavium, Inc Official Website @@ -14,14 +14,14 @@ More information can be found at `Cavium, Inc Official Website Features -------- -Features of the OCTEONTX FPAVF PMD are: +Features of the OCTEON TX FPAVF PMD are: - 32 SR-IOV Virtual functions - 32 Pools - HW mempool manager -Supported OCTEONTX SoCs ------------------------ +Supported OCTEON TX SoCs +------------------------ - CN83xx @@ -50,7 +50,7 @@ Please note that enabling debugging options may affect system performance. Driver Compilation ~~~~~~~~~~~~~~~~~~ -To compile the OCTEONTX FPAVF MEMPOOL PMD for Linux arm64 gcc target, run the +To compile the OCTEON TX FPAVF MEMPOOL PMD for Linux arm64 gcc target, run the following ``make`` command: .. code-block:: console @@ -62,7 +62,7 @@ following ``make`` command: Initialization -------------- -The octeontx fpavf mempool initialization similar to other mempool +The OCTEON TX fpavf mempool initialization similar to other mempool drivers like ring. However user need to pass --base-virtaddr as command line input to application example test_mempool.c application. diff --git a/doc/guides/meson.build b/doc/guides/meson.build new file mode 100644 index 00000000..06f14882 --- /dev/null +++ b/doc/guides/meson.build @@ -0,0 +1,28 @@ +# SPDX-License-Identifier: BSD-3-Clause +# Copyright(c) 2018 Intel Corporation + +sphinx = find_program('sphinx-build', required: get_option('enable_docs')) + +if sphinx.found() + htmldir = join_paths('share', 'doc', 'dpdk') + html_guides_build = custom_target('html_guides_build', + input: meson.current_source_dir(), + output: 'guides', + command: [sphinx, '-b', 'html', + '-d', meson.current_build_dir() + '/.doctrees', + '@INPUT@', meson.current_build_dir() + '/guides'], + build_by_default: false, + install: get_option('enable_docs'), + install_dir: htmldir) + + doc_targets += html_guides_build + doc_target_names += 'HTML_Guides' + + # sphinx leaves a .buildinfo in the target directory, which we don't + # want to install. Note that sh -c has to be used, otherwise the + # env var does not get expanded if calling rm/install directly. + meson.add_install_script('sh', '-c', + 'rm -f $MESON_INSTALL_DESTDIR_PREFIX/share/doc/dpdk/guides/.buildinfo') + meson.add_install_script('sh', '-c', + 'install -D -m0644 $MESON_SOURCE_ROOT/doc/guides/custom.css $MESON_INSTALL_DESTDIR_PREFIX/share/doc/dpdk/guides/_static/css/custom.css') +endif diff --git a/doc/guides/nics/atlantic.rst b/doc/guides/nics/atlantic.rst new file mode 100644 index 00000000..80591b13 --- /dev/null +++ b/doc/guides/nics/atlantic.rst @@ -0,0 +1,47 @@ +.. SPDX-License-Identifier: BSD-3-Clause + Copyright(c) 2018 Aquantia Corporation. + +Aquantia Atlantic DPDK Driver +============================= + +Atlantic DPDK driver provides DPDK support for Aquantia's AQtion family of chipsets: AQC107/AQC108/AQC109 + +More information can be found at `Aquantia Official Website +<https://www.aquantia.com/products/client-connectivity/>`_. + +Supported features +^^^^^^^^^^^^^^^^^^ + +- Base L2 features +- Promiscuous mode +- Multicast mode +- Port statistics +- RSS (Receive Side Scaling) +- Checksum offload +- Jumbo Frame upto 16K + +Configuration Information +^^^^^^^^^^^^^^^^^^^^^^^^^ + +- ``CONFIG_RTE_LIBRTE_ATLANTIC_PMD`` (default ``y``) + +Application Programming Interface +--------------------------------- + +Limitations or Known issues +--------------------------- + +Statistics +~~~~~~~~~~ + +MTU setting +~~~~~~~~~~~ + +Atlantic NIC supports up to 16K jumbo frame size + +Supported Chipsets and NICs +--------------------------- + +- Aquantia AQtion AQC107 10 Gigabit Ethernet Controller +- Aquantia AQtion AQC108 5 Gigabit Ethernet Controller +- Aquantia AQtion AQC109 2.5 Gigabit Ethernet Controller diff --git a/doc/guides/nics/axgbe.rst b/doc/guides/nics/axgbe.rst index e30f4944..9b270a42 100644 --- a/doc/guides/nics/axgbe.rst +++ b/doc/guides/nics/axgbe.rst @@ -24,7 +24,7 @@ AXGBE PMD has support for: - Multicast mode - RSS (Receive Side Scaling) - Checksum offload -- Jumbo Frame upto 9K +- Jumbo Frame up to 9K Configuration Information diff --git a/doc/guides/nics/dpaa2.rst b/doc/guides/nics/dpaa2.rst index 66c03e10..e2f385d4 100644 --- a/doc/guides/nics/dpaa2.rst +++ b/doc/guides/nics/dpaa2.rst @@ -558,7 +558,7 @@ which are lower than logging ``level``. <dpdk app> <EAL args> --log-level=pmd.net.dpaa2:<level> -- ... -Using ``pmd.dpaa2`` as log matching criteria, all PMD logs can be enabled +Using ``pmd.net.dpaa2`` as log matching criteria, all PMD logs can be enabled which are lower than logging ``level``. Whitelisting & Blacklisting diff --git a/doc/guides/nics/ena.rst b/doc/guides/nics/ena.rst index d19912e9..34c48575 100644 --- a/doc/guides/nics/ena.rst +++ b/doc/guides/nics/ena.rst @@ -113,10 +113,6 @@ Configuration information * **CONFIG_RTE_LIBRTE_ENA_PMD** (default y): Enables or disables inclusion of the ENA PMD driver in the DPDK compilation. - - * **CONFIG_RTE_LIBRTE_ENA_DEBUG_INIT** (default y): Enables or disables debug - logging of device initialization within the ENA PMD driver. - * **CONFIG_RTE_LIBRTE_ENA_DEBUG_RX** (default n): Enables or disables debug logging of RX logic within the ENA PMD driver. @@ -187,11 +183,20 @@ Prerequisites ------------- #. Prepare the system as recommended by DPDK suite. This includes environment - variables, hugepages configuration, tool-chains and configuration + variables, hugepages configuration, tool-chains and configuration. + +#. ENA PMD can operate with ``vfio-pci`` or ``igb_uio`` driver. + +#. Insert ``vfio-pci`` or ``igb_uio`` kernel module using the command + ``modprobe vfio-pci`` or ``modprobe igb_uio`` respectively. + +#. For ``vfio-pci`` users only: + Please make sure that ``IOMMU`` is enabled in your system, + or use ``vfio`` driver in ``noiommu`` mode:: -#. Insert igb_uio kernel module using the command 'modprobe igb_uio' + echo 1 > /sys/module/vfio/parameters/enable_unsafe_noiommu_mode -#. Bind the intended ENA device to igb_uio module +#. Bind the intended ENA device to ``vfio-pci`` or ``igb_uio`` module. At this point the system should be ready to run DPDK applications. Once the diff --git a/doc/guides/nics/enetc.rst b/doc/guides/nics/enetc.rst new file mode 100644 index 00000000..8038bf20 --- /dev/null +++ b/doc/guides/nics/enetc.rst @@ -0,0 +1,110 @@ +.. SPDX-License-Identifier: BSD-3-Clause + Copyright 2018 NXP + +ENETC Poll Mode Driver +====================== + +The ENETC NIC PMD (**librte_pmd_enetc**) provides poll mode driver +support for the inbuilt NIC found in the **NXP LS1028** SoC. + +More information can be found at `NXP Official Website +<https://www.nxp.com/products/processors-and-microcontrollers/arm-based-processors-and-mcus/qoriq-layerscape-arm-processors/qoriq-layerscape-1028a-industrial-applications-processor:LS1028A>`_. + +ENETC +----- + +This section provides an overview of the NXP ENETC +and how it is integrated into the DPDK. + +Contents summary + +- ENETC overview +- ENETC features +- PCI bus driver +- NIC driver +- Supported ENETC SoCs +- Prerequisites +- Driver compilation and testing + +ENETC Overview +~~~~~~~~~~~~~~ + +ENETC is a PCI Integrated End Point(IEP). IEP implements +peripheral devices in an SoC such that software sees them as PCIe device. +ENETC is an evolution of BDR(Buffer Descriptor Ring) based networking +IPs. + +This infrastructure simplifies adding support for IEP and facilitates in following: + +- Device discovery and location +- Resource requirement discovery and allocation (e.g. interrupt assignment, + device register address) +- Event reporting + +ENETC Features +~~~~~~~~~~~~~~ + +- Link Status +- Packet type information + +NIC Driver (PMD) +~~~~~~~~~~~~~~~~ + +ENETC PMD is traditional DPDK PMD which provides necessary interface between +RTE framework and ENETC internal drivers. + +- Driver registers the device vendor table in PCI subsystem. +- RTE framework scans the PCI bus for connected devices. +- This scanning will invoke the probe function of ENETC driver. +- The probe function will set the basic device registers and also setups BD rings. +- On packet Rx the respective BD Ring status bit is set which is then used for + packet processing. +- Then Tx is done first followed by Rx. + +Supported ENETC SoCs +~~~~~~~~~~~~~~~~~~~~ + +- LS1028 + +Prerequisites +~~~~~~~~~~~~~ + +There are three main pre-requisities for executing ENETC PMD on a ENETC +compatible board: + +1. **ARM 64 Tool Chain** + + For example, the `*aarch64* Linaro Toolchain <https://releases.linaro.org/components/toolchain/binaries/7.3-2018.05/aarch64-linux-gnu/gcc-linaro-7.3.1-2018.05-i686_aarch64-linux-gnu.tar.xz>`_. + +2. **Linux Kernel** + + It can be obtained from `NXP's Github hosting <https://source.codeaurora.org/external/qoriq/qoriq-components/linux>`_. + +3. **Rootfile system** + + Any *aarch64* supporting filesystem can be used. For example, + Ubuntu 16.04 LTS (Xenial) or 18.04 (Bionic) userland which can be obtained + from `here <http://cdimage.ubuntu.com/ubuntu-base/releases/18.04/release/ubuntu-base-18.04.1-base-arm64.tar.gz>`_. + +The following dependencies are not part of DPDK and must be installed +separately: + +- **NXP Linux LSDK** + + NXP Layerscape software development kit (LSDK) includes support for family + of QorIQ® ARM-Architecture-based system on chip (SoC) processors + and corresponding boards. + + It includes the Linux board support packages (BSPs) for NXP SoCs, + a fully operational tool chain, kernel and board specific modules. + + LSDK and related information can be obtained from: `LSDK <https://www.nxp.com/support/developer-resources/run-time-software/linux-software-and-development-tools/layerscape-software-development-kit:LAYERSCAPE-SDK>`_ + +Driver compilation and testing +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Follow instructions available in the document +:ref:`compiling and testing a PMD for a NIC <pmd_build_and_test>` +to launch **testpmd** + +To compile in performance mode, please set ``CONFIG_RTE_CACHE_LINE_SIZE=64`` diff --git a/doc/guides/nics/enic.rst b/doc/guides/nics/enic.rst index 438a83d5..746d8912 100644 --- a/doc/guides/nics/enic.rst +++ b/doc/guides/nics/enic.rst @@ -260,6 +260,12 @@ Generic Flow API is supported. The baseline support is: - Selectors: 'is', 'spec' and 'mask'. 'last' is not supported - In total, up to 64 bytes of mask is allowed across all headers +- **1400 and later series VICS with advanced filters enabled** + + All the above plus: + + - Action: count + More features may be added in future firmware and new versions of the VIC. Please refer to the release notes. @@ -345,6 +351,41 @@ suitable for others. Such applications may change the mode by setting applications such as OVS-DPDK performance benchmarks that utilize only the default VLAN and want to see only untagged packets. + +Vectorized Rx Handler +--------------------- + +ENIC PMD includes a version of the receive handler that is vectorized using +AVX2 SIMD instructions. It is meant for bulk, throughput oriented workloads +where reducing cycles/packet in PMD is a priority. In order to use the +vectorized handler, take the following steps. + +- Use a recent version of gcc, icc, or clang and build 64-bit DPDK. If + the compiler is known to support AVX2, DPDK build system + automatically compiles the vectorized handler. Otherwise, the + handler is not available. + +- Set ``devargs`` parameter ``enable-avx2-rx=1`` to explicitly request that + PMD consider the vectorized handler when selecting the receive handler. + For example:: + + -w 12:00.0,enable-avx2-rx=1 + + As the current implementation is intended for field trials, by default, the + vectorized handler is not considered (``enable-avx2-rx=0``). + +- Run on a UCS M4 or later server with CPUs that support AVX2. + +PMD selects the vectorized handler when the handler is compiled into +the driver, the user requests its use via ``enable-avx2-rx=1``, CPU +supports AVX2, and scatter Rx is not used. To verify that the +vectorized handler is selected, enable debug logging +(``--log-level=pmd,debug``) and check the following message. + +.. code-block:: console + + enic_use_vector_rx_handler use the non-scatter avx2 Rx handler + .. _enic_limitations: Limitations diff --git a/doc/guides/nics/features.rst b/doc/guides/nics/features.rst index cddc877d..3fa5cb74 100644 --- a/doc/guides/nics/features.rst +++ b/doc/guides/nics/features.rst @@ -513,8 +513,9 @@ CRC offload ----------- Supports CRC stripping by hardware. +A PMD assumed to support CRC stripping by default. PMD should advertise if it supports keeping CRC. -* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:DEV_RX_OFFLOAD_CRC_STRIP,DEV_RX_OFFLOAD_KEEP_CRC``. +* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:DEV_RX_OFFLOAD_KEEP_CRC``. .. _nic_features_vlan_offload: @@ -526,8 +527,9 @@ Supports VLAN offload to hardware. * **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:DEV_RX_OFFLOAD_VLAN_STRIP,DEV_RX_OFFLOAD_VLAN_FILTER,DEV_RX_OFFLOAD_VLAN_EXTEND``. * **[uses] rte_eth_txconf,rte_eth_txmode**: ``offloads:DEV_TX_OFFLOAD_VLAN_INSERT``. +* **[uses] mbuf**: ``mbuf.ol_flags:PKT_TX_VLAN``, ``mbuf.vlan_tci``. * **[implements] eth_dev_ops**: ``vlan_offload_set``. -* **[provides] mbuf**: ``mbuf.ol_flags:PKT_RX_VLAN_STRIPPED``, ``mbuf.vlan_tci``. +* **[provides] mbuf**: ``mbuf.ol_flags:PKT_RX_VLAN_STRIPPED``, ``mbuf.ol_flags:PKT_RX_VLAN`` ``mbuf.vlan_tci``. * **[provides] rte_eth_dev_info**: ``rx_offload_capa,rx_queue_offload_capa:DEV_RX_OFFLOAD_VLAN_STRIP``, ``tx_offload_capa,tx_queue_offload_capa:DEV_TX_OFFLOAD_VLAN_INSERT``. * **[related] API**: ``rte_eth_dev_set_vlan_offload()``, @@ -543,9 +545,10 @@ Supports QinQ (queue in queue) offload. * **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:DEV_RX_OFFLOAD_QINQ_STRIP``. * **[uses] rte_eth_txconf,rte_eth_txmode**: ``offloads:DEV_TX_OFFLOAD_QINQ_INSERT``. -* **[uses] mbuf**: ``mbuf.ol_flags:PKT_TX_QINQ_PKT``. -* **[provides] mbuf**: ``mbuf.ol_flags:PKT_RX_QINQ_STRIPPED``, ``mbuf.vlan_tci``, - ``mbuf.vlan_tci_outer``. +* **[uses] mbuf**: ``mbuf.ol_flags:PKT_TX_QINQ``, ``mbuf.vlan_tci_outer``. +* **[provides] mbuf**: ``mbuf.ol_flags:PKT_RX_QINQ_STRIPPED``, ``mbuf.ol_flags:PKT_RX_QINQ``, + ``mbuf.ol_flags:PKT_RX_VLAN_STRIPPED``, ``mbuf.ol_flags:PKT_RX_VLAN`` + ``mbuf.vlan_tci``, ``mbuf.vlan_tci_outer``. * **[provides] rte_eth_dev_info**: ``rx_offload_capa,rx_queue_offload_capa:DEV_RX_OFFLOAD_QINQ_STRIP``, ``tx_offload_capa,tx_queue_offload_capa:DEV_TX_OFFLOAD_QINQ_INSERT``. @@ -561,6 +564,7 @@ Supports L3 checksum offload. * **[uses] rte_eth_txconf,rte_eth_txmode**: ``offloads:DEV_TX_OFFLOAD_IPV4_CKSUM``. * **[uses] mbuf**: ``mbuf.ol_flags:PKT_TX_IP_CKSUM``, ``mbuf.ol_flags:PKT_TX_IPV4`` | ``PKT_TX_IPV6``. +* **[uses] mbuf**: ``mbuf.l2_len``, ``mbuf.l3_len``. * **[provides] mbuf**: ``mbuf.ol_flags:PKT_RX_IP_CKSUM_UNKNOWN`` | ``PKT_RX_IP_CKSUM_BAD`` | ``PKT_RX_IP_CKSUM_GOOD`` | ``PKT_RX_IP_CKSUM_NONE``. @@ -575,15 +579,16 @@ L4 checksum offload Supports L4 checksum offload. -* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:DEV_RX_OFFLOAD_UDP_CKSUM,DEV_RX_OFFLOAD_TCP_CKSUM``. +* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:DEV_RX_OFFLOAD_UDP_CKSUM,DEV_RX_OFFLOAD_TCP_CKSUM,DEV_RX_OFFLOAD_SCTP_CKSUM``. * **[uses] rte_eth_txconf,rte_eth_txmode**: ``offloads:DEV_TX_OFFLOAD_UDP_CKSUM,DEV_TX_OFFLOAD_TCP_CKSUM,DEV_TX_OFFLOAD_SCTP_CKSUM``. * **[uses] mbuf**: ``mbuf.ol_flags:PKT_TX_IPV4`` | ``PKT_TX_IPV6``, ``mbuf.ol_flags:PKT_TX_L4_NO_CKSUM`` | ``PKT_TX_TCP_CKSUM`` | ``PKT_TX_SCTP_CKSUM`` | ``PKT_TX_UDP_CKSUM``. +* **[uses] mbuf**: ``mbuf.l2_len``, ``mbuf.l3_len``. * **[provides] mbuf**: ``mbuf.ol_flags:PKT_RX_L4_CKSUM_UNKNOWN`` | ``PKT_RX_L4_CKSUM_BAD`` | ``PKT_RX_L4_CKSUM_GOOD`` | ``PKT_RX_L4_CKSUM_NONE``. -* **[provides] rte_eth_dev_info**: ``rx_offload_capa,rx_queue_offload_capa:DEV_RX_OFFLOAD_UDP_CKSUM,DEV_RX_OFFLOAD_TCP_CKSUM``, +* **[provides] rte_eth_dev_info**: ``rx_offload_capa,rx_queue_offload_capa:DEV_RX_OFFLOAD_UDP_CKSUM,DEV_RX_OFFLOAD_TCP_CKSUM,DEV_RX_OFFLOAD_SCTP_CKSUM``, ``tx_offload_capa,tx_queue_offload_capa:DEV_TX_OFFLOAD_UDP_CKSUM,DEV_TX_OFFLOAD_TCP_CKSUM,DEV_TX_OFFLOAD_SCTP_CKSUM``. .. _nic_features_hw_timestamp: @@ -638,6 +643,16 @@ Inner L4 checksum Supports inner packet L4 checksum. +* **[uses] rte_eth_rxconf,rte_eth_rxmode**: ``offloads:DEV_RX_OFFLOAD_OUTER_UDP_CKSUM``. +* **[provides] mbuf**: ``mbuf.ol_flags:PKT_RX_OUTER_L4_CKSUM_UNKNOWN`` | + ``PKT_RX_OUTER_L4_CKSUM_BAD`` | ``PKT_RX_OUTER_L4_CKSUM_GOOD`` | ``PKT_RX_OUTER_L4_CKSUM_INVALID``. +* **[uses] rte_eth_txconf,rte_eth_txmode**: ``offloads:DEV_TX_OFFLOAD_OUTER_UDP_CKSUM``. +* **[uses] mbuf**: ``mbuf.ol_flags:PKT_TX_OUTER_IPV4`` | ``PKT_TX_OUTER_IPV6``. + ``mbuf.ol_flags:PKT_TX_OUTER_UDP_CKSUM``. +* **[uses] mbuf**: ``mbuf.outer_l2_len``, ``mbuf.outer_l3_len``. +* **[provides] rte_eth_dev_info**: ``rx_offload_capa,rx_queue_offload_capa:DEV_RX_OFFLOAD_OUTER_UDP_CKSUM``, + ``tx_offload_capa,tx_queue_offload_capa:DEV_TX_OFFLOAD_OUTER_UDP_CKSUM``. + .. _nic_features_packet_type_parsing: diff --git a/doc/guides/nics/features/atlantic.ini b/doc/guides/nics/features/atlantic.ini new file mode 100644 index 00000000..5ed095b1 --- /dev/null +++ b/doc/guides/nics/features/atlantic.ini @@ -0,0 +1,37 @@ +; +; Supported features of the 'atlantic' network poll mode driver. +; +; Refer to default.ini for the full list of available PMD features. +; +[Features] +Speed capabilities = Y +Link status = Y +Link status event = Y +Queue start/stop = Y +MTU update = Y +Jumbo frame = Y +Promiscuous mode = Y +Allmulticast mode = Y +Unicast MAC filter = Y +RSS hash = Y +RSS key update = Y +RSS reta update = Y +VLAN filter = Y +Flow control = Y +CRC offload = Y +VLAN offload = Y +L3 checksum offload = Y +L4 checksum offload = Y +Packet type parsing = Y +Rx descriptor status = Y +Tx descriptor status = Y +Basic stats = Y +Extended stats = Y +Stats per queue = Y +FW version = Y +EEPROM dump = Y +Registers dump = Y +Linux UIO = Y +ARMv8 = Y +x86-32 = Y +x86-64 = Y diff --git a/doc/guides/nics/features/ena.ini b/doc/guides/nics/features/ena.ini index 691c1e3d..aa6f05a7 100644 --- a/doc/guides/nics/features/ena.ini +++ b/doc/guides/nics/features/ena.ini @@ -23,5 +23,6 @@ Inner L4 checksum = Y Basic stats = Y Extended stats = Y Linux UIO = Y +Linux VFIO = Y x86-32 = Y x86-64 = Y diff --git a/doc/guides/nics/features/enetc.ini b/doc/guides/nics/features/enetc.ini new file mode 100644 index 00000000..69476a2a --- /dev/null +++ b/doc/guides/nics/features/enetc.ini @@ -0,0 +1,11 @@ +; +; Supported features of the 'enetc' network poll mode driver. +; +; Refer to default.ini for the full list of available PMD features. +; +[Features] +Packet type parsing = Y +Link status = Y +Linux VFIO = Y +ARMv8 = Y +Usage doc = Y diff --git a/doc/guides/nics/features/failsafe.ini b/doc/guides/nics/features/failsafe.ini index 39ee5796..e3c4c08f 100644 --- a/doc/guides/nics/features/failsafe.ini +++ b/doc/guides/nics/features/failsafe.ini @@ -7,6 +7,9 @@ Link status = Y Link status event = Y Rx interrupt = Y +Queue start/stop = Y +Runtime Rx queue setup = Y +Runtime Tx queue setup = Y MTU update = Y Jumbo frame = Y Promiscuous mode = Y diff --git a/doc/guides/nics/features/mvneta.ini b/doc/guides/nics/features/mvneta.ini new file mode 100644 index 00000000..701eb03d --- /dev/null +++ b/doc/guides/nics/features/mvneta.ini @@ -0,0 +1,19 @@ +; +; Supported features of the 'mvneta' network poll mode driver. +; +; Refer to default.ini for the full list of available PMD features. +; +[Features] +Speed capabilities = Y +Link status = Y +MTU update = Y +Jumbo frame = Y +Promiscuous mode = Y +Unicast MAC filter = Y +CRC offload = Y +L3 checksum offload = Y +L4 checksum offload = Y +Packet type parsing = Y +Basic stats = Y +ARMv8 = Y +Usage doc = Y diff --git a/doc/guides/nics/features/netvsc.ini b/doc/guides/nics/features/netvsc.ini index 2ff6042b..f5dc1e78 100644 --- a/doc/guides/nics/features/netvsc.ini +++ b/doc/guides/nics/features/netvsc.ini @@ -6,6 +6,7 @@ [Features] Speed capabilities = P Link status = Y +Free Tx mbuf on demand = Y Queue start/stop = Y Scattered Rx = Y Promiscuous mode = Y diff --git a/doc/guides/nics/features/sfc_efx.ini b/doc/guides/nics/features/sfc_efx.ini index 8a497ee0..d1aa8331 100644 --- a/doc/guides/nics/features/sfc_efx.ini +++ b/doc/guides/nics/features/sfc_efx.ini @@ -9,6 +9,8 @@ Link status = Y Link status event = Y Fast mbuf free = Y Queue start/stop = Y +Runtime Rx queue setup = Y +Runtime Tx queue setup = Y MTU update = Y Jumbo frame = Y Scattered Rx = Y diff --git a/doc/guides/nics/fm10k.rst b/doc/guides/nics/fm10k.rst index d1391e99..764e089c 100644 --- a/doc/guides/nics/fm10k.rst +++ b/doc/guides/nics/fm10k.rst @@ -139,8 +139,7 @@ CRC striping ~~~~~~~~~~~~ The FM10000 family of NICs strip the CRC for every packets coming into the -host interface. So, CRC will be stripped even when ``DEV_RX_OFFLOAD_CRC_STRIP`` -in ``rxmode.offloads`` is NOT set in ``struct rte_eth_conf``. +host interface. So, keeping CRC is not supported. Maximum packet length ~~~~~~~~~~~~~~~~~~~~~ diff --git a/doc/guides/nics/i40e.rst b/doc/guides/nics/i40e.rst index 65d87f86..ab3928a6 100644 --- a/doc/guides/nics/i40e.rst +++ b/doc/guides/nics/i40e.rst @@ -163,6 +163,15 @@ Runtime Config Options Currently hot-plugging of representor ports is not supported so all required representors must be specified on the creation of the PF. +- ``Use latest supported vector`` (default ``disable``) + + Latest supported vector path may not always get the best perf so vector path was + recommended to use only on later platform. But users may want the latest vector path + since it can get better perf in some real work loading cases. So ``devargs`` param + ``use-latest-supported-vec`` is introduced, for example:: + + -w 84:00.0,use-latest-supported-vec=1 + Driver compilation and testing ------------------------------ @@ -421,6 +430,12 @@ functionality requires a NIC firmware version of 6.0 or greater. Current implementation supports GTP-C/GTP-U/PPPoE/PPPoL2TP, steering can be used with rte_flow API. +GTPv1 package is released, and it can be downloaded from +https://downloadcenter.intel.com/download/27587. + +PPPoE package is released, and it can be downloaded from +https://downloadcenter.intel.com/download/28040. + Load a profile which supports GTP and store backup profile: .. code-block:: console diff --git a/doc/guides/nics/img/mvpp2_tm.svg b/doc/guides/nics/img/mvpp2_tm.svg new file mode 100644 index 00000000..4aa92721 --- /dev/null +++ b/doc/guides/nics/img/mvpp2_tm.svg @@ -0,0 +1,71 @@ +<?xml version="1.0" encoding="UTF-8" standalone="no"?> +<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/PR-SVG-20010719/DTD/svg10.dtd"> +<svg width="16cm" height="4cm" viewBox="-1 -1 309 75" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"> + <g> + <polyline style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #000000" points="159.661,12.6759 141.655,12.6759 141.655,35.5606 88.1561,35.5606 88.1561,44.9245 "/> + <polygon style="fill: #000000" points="88.1561,49.4245 85.1561,43.4245 88.1561,44.9245 91.1561,43.4245 "/> + <polygon style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #000000" points="88.1561,49.4245 85.1561,43.4245 88.1561,44.9245 91.1561,43.4245 "/> + </g> + <g> + <polyline style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #000000" points="159.661,12.6759 176.28,12.6759 176.28,35.5606 281.681,35.5606 281.681,44.9245 "/> + <polygon style="fill: #000000" points="281.681,49.4245 278.681,43.4245 281.681,44.9245 284.681,43.4245 "/> + <polygon style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #000000" points="281.681,49.4245 278.681,43.4245 281.681,44.9245 284.681,43.4245 "/> + </g> + <g> + <rect style="fill: #ffffff" x="126.066" y="0.98102" width="67.1901" height="23.3899"/> + <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="126.066" y="0.98102" width="67.1901" height="23.3899"/> + </g> + <text font-size="12.7998" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="159.661" y="17.1259"> + <tspan x="159.661" y="17.1259">Port N</tspan> + </text> + <text font-size="12.7998" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="304.581" y="68.168"> + <tspan x="304.581" y="68.168"></tspan> + </text> + <g> + <rect style="fill: #ffffff" x="62.5504" y="51.5478" width="51.2114" height="22.0925"/> + <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="62.5504" y="51.5478" width="51.2114" height="22.0925"/> + </g> + <text font-size="12.7998" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="88.1561" y="67.044"> + <tspan x="88.1561" y="67.044">Txq 0</tspan> + </text> + <g> + <rect style="fill: #ffffff" x="134.1" y="51.355" width="51.1213" height="22.478"/> + <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="134.1" y="51.355" width="51.1213" height="22.478"/> + </g> + <text font-size="12.7998" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="159.661" y="67.044"> + <tspan x="159.661" y="67.044">Txq 1</tspan> + </text> + <g> + <rect style="fill: #ffffff" x="256.416" y="51.5478" width="50.5306" height="22.0925"/> + <rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="256.416" y="51.5478" width="50.5306" height="22.0925"/> + </g> + <text font-size="12.7998" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="281.681" y="67.044"> + <tspan x="281.681" y="67.044">Txq M</tspan> + </text> + <text font-size="12.7998" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="101.822" y="67.044"> + <tspan x="101.822" y="67.044"></tspan> + </text> + <text font-size="12.7998" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="-0.537645" y="17.1259"> + <tspan x="-0.537645" y="17.1259">Level 0:</tspan> + </text> + <text font-size="12.7998" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="-0.746688" y="67.044"> + <tspan x="-0.746688" y="67.044">Level 1:</tspan> + </text> + <g> + <ellipse style="fill: #000000" cx="207.645" cy="62.594" rx="0.425344" ry="0.425344"/> + <ellipse style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" cx="207.645" cy="62.594" rx="0.425344" ry="0.425344"/> + </g> + <g> + <ellipse style="fill: #000000" cx="219.525" cy="62.594" rx="0.425344" ry="0.425344"/> + <ellipse style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" cx="219.525" cy="62.594" rx="0.425344" ry="0.425344"/> + </g> + <g> + <ellipse style="fill: #000000" cx="231.405" cy="62.594" rx="0.425345" ry="0.425345"/> + <ellipse style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" cx="231.405" cy="62.594" rx="0.425345" ry="0.425345"/> + </g> + <g> + <line style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #000000" x1="159.661" y1="24.3709" x2="159.661" y2="45.737"/> + <polygon style="fill: #000000" points="159.661,50.237 156.661,44.237 159.661,45.737 162.661,44.237 "/> + <polygon style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #000000" points="159.661,50.237 156.661,44.237 159.661,45.737 162.661,44.237 "/> + </g> +</svg> diff --git a/doc/guides/nics/index.rst b/doc/guides/nics/index.rst index 59f6063d..bb107ae5 100644 --- a/doc/guides/nics/index.rst +++ b/doc/guides/nics/index.rst @@ -12,6 +12,7 @@ Network Interface Controller Drivers features build_and_test ark + atlantic avp axgbe bnx2x @@ -21,6 +22,7 @@ Network Interface Controller Drivers dpaa2 e1000em ena + enetc enic fm10k i40e @@ -32,6 +34,7 @@ Network Interface Controller Drivers liquidio mlx4 mlx5 + mvneta mvpp2 netvsc nfp diff --git a/doc/guides/nics/ixgbe.rst b/doc/guides/nics/ixgbe.rst index 16d63902..1c294b06 100644 --- a/doc/guides/nics/ixgbe.rst +++ b/doc/guides/nics/ixgbe.rst @@ -200,6 +200,33 @@ There is no RTE API to add a VF's MAC address from the PF. On ixgbe, the ``rte_eth_dev_mac_addr_add()`` function can be used to add a VF's MAC address, as a workaround. +X550 does not support legacy interrupt mode +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Desccription +^^^^^^^^^^^^ +X550 cannot get interrupts if using ``uio_pci_generic`` module or using legacy +interrupt mode of ``igb_uio`` or ``vfio``. Because the errata of X550 states +that the Interrupt Status bit is not implemented. The errata is the item #22 +from `X550 spec update <https://www.intel.com/content/dam/www/public/us/en/ +documents/specification-updates/ethernet-x550-spec-update.pdf>`_ + +Implication +^^^^^^^^^^^ +When using ``uio_pci_generic`` module or using legacy interrupt mode of +``igb_uio`` or ``vfio``, the Interrupt Status bit would be checked if the +interrupt is coming. Since the bit is not implemented in X550, the irq cannot +be handled correctly and cannot report the event fd to DPDK apps. Then apps +cannot get interrupts and ``dmesg`` will show messages like ``irq #No.: `` +``nobody cared.`` + +Workaround +^^^^^^^^^^ +Do not bind the ``uio_pci_generic`` module in X550 NICs. +Do not bind ``igb_uio`` with legacy mode in X550 NICs. +Before binding ``vfio`` with legacy mode in X550 NICs, use ``modprobe vfio `` +``nointxmask=1`` to load ``vfio`` module if the intx is not shared with other +devices. Inline crypto processing support -------------------------------- diff --git a/doc/guides/nics/liquidio.rst b/doc/guides/nics/liquidio.rst index 87b42cdc..e2a38004 100644 --- a/doc/guides/nics/liquidio.rst +++ b/doc/guides/nics/liquidio.rst @@ -30,14 +30,6 @@ Please note that enabling debugging options may affect system performance. Toggle compilation of LiquidIO PMD. -- ``CONFIG_RTE_LIBRTE_LIO_DEBUG_DRIVER`` (default ``n``) - - Toggle display of generic debugging messages. - -- ``CONFIG_RTE_LIBRTE_LIO_DEBUG_INIT`` (default ``n``) - - Toggle display of initialization related messages. - - ``CONFIG_RTE_LIBRTE_LIO_DEBUG_RX`` (default ``n``) Toggle display of receive fast path run-time messages. diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst index 52e1213c..67696283 100644 --- a/doc/guides/nics/mlx5.rst +++ b/doc/guides/nics/mlx5.rst @@ -339,7 +339,12 @@ Run-time configuration When those offloads are requested the MPS send function will not be used. It is currently only supported on the ConnectX-4 Lx, ConnectX-5 and Bluefield - families of adapters. Enabled by default. + families of adapters. + On ConnectX-4 Lx the MPW is considered un-secure hence disabled by default. + Users which enable the MPW should be aware that application which provides incorrect + mbuf descriptors in the Tx burst can lead to serious errors in the host including, on some cases, + NIC to get stuck. + On ConnectX-5 and Bluefield the MPW is secure and enabled by default. - ``txq_mpw_hdr_dseg_en`` parameter [int] @@ -392,6 +397,13 @@ Run-time configuration Disabled by default. +- ``dv_flow_en`` parameter [int] + + A nonzero value enables the DV flow steering assuming it is supported + by the driver. + + Disabled by default. + - ``representor`` parameter [list] This parameter can be used to instantiate DPDK Ethernet devices from diff --git a/doc/guides/nics/mvneta.rst b/doc/guides/nics/mvneta.rst new file mode 100644 index 00000000..2132a819 --- /dev/null +++ b/doc/guides/nics/mvneta.rst @@ -0,0 +1,171 @@ +.. SPDX-License-Identifier: BSD-3-Clause + Copyright(c) 2018 Marvell International Ltd. + Copyright(c) 2018 Semihalf. + All rights reserved. + +MVNETA Poll Mode Driver +======================= + +The MVNETA PMD (librte_pmd_mvneta) provides poll mode driver support +for the Marvell NETA 1/2.5 Gbps adapter. + +Detailed information about SoCs that use PPv2 can be obtained here: + +* https://www.marvell.com/embedded-processors/armada-3700/ + +.. Note:: + + Due to external dependencies, this driver is disabled by default. It must + be enabled manually by setting relevant configuration option manually. + Please refer to `Config File Options`_ section for further details. + + +Features +-------- + +Features of the MVNETA PMD are: + +- Start/stop +- tx/rx_queue_setup +- tx/rx_burst +- Speed capabilities +- Jumbo frame +- MTU update +- Promiscuous mode +- Unicast MAC filter +- Link status +- CRC offload +- L3 checksum offload +- L4 checksum offload +- Packet type parsing +- Basic stats + + +Limitations +----------- + +- Flushing vlans added for filtering is not possible due to MUSDK missing + functionality. Current workaround is to reset board so that NETA has a + chance to start in a sane state. + +Prerequisites +------------- + +- Custom Linux Kernel sources + + .. code-block:: console + + git clone https://github.com/MarvellEmbeddedProcessors/linux-marvell.git -b linux-4.4.120-armada-18.09 + + +- MUSDK (Marvell User-Space SDK) sources + + .. code-block:: console + + git clone https://github.com/MarvellEmbeddedProcessors/musdk-marvell.git -b musdk-armada-18.09 + + MUSDK is a light-weight library that provides direct access to Marvell's + NETA. Alternatively prebuilt MUSDK library can be + requested from `Marvell Extranet <https://extranet.marvell.com>`_. Once + approval has been granted, library can be found by typing ``musdk`` in + the search box. + + MUSDK must be configured with the following features: + + .. code-block:: console + + --enable-pp2=no --enable-neta + +- DPDK environment + + Follow the DPDK :ref:`Getting Started Guide for Linux <linux_gsg>` to setup + DPDK environment. + +Pre-Installation Configuration +------------------------------ + +Config File Options +~~~~~~~~~~~~~~~~~~~ + +The following options can be modified in the ``config`` file. + +- ``CONFIG_RTE_LIBRTE_MVNETA_PMD`` (default ``n``) + + Toggle compilation of the librte_pmd_mvneta driver. + +Runtime options +~~~~~~~~~~~~~~~ + +The following ``devargs`` options can be enabled at runtime. They must +be passed as part of EAL arguments. + +- ``iface`` (mandatory, with no default value) + + The name of port (owned by MUSDK) that should be enabled in DPDK. + This options can be repeated resulting in a list of ports to be + enabled. For instance below will enable ``eth0`` and ``eth1`` ports. + +.. code-block:: console + + ./testpmd --vdev=net_mvneta,iface=eth0,iface=eth1 \ + -c 3 -- -i --p 3 -a + + +Building DPDK +------------- + +Driver needs precompiled MUSDK library during compilation. + +.. code-block:: console + + export CROSS_COMPILE=<toolchain>/bin/aarch64-linux-gnu- + ./bootstrap + ./configure --host=aarch64-linux-gnu --enable-pp2=no --enable-neta + make install + +MUSDK will be installed to `usr/local` under current directory. +For the detailed build instructions please consult ``doc/musdk_get_started.txt``. + +Before the DPDK build process the environmental variable ``LIBMUSDK_PATH`` with +the path to the MUSDK installation directory needs to be exported. + +.. code-block:: console + + export LIBMUSDK_PATH=<musdk>/usr/local + export CROSS=aarch64-linux-gnu- + make config T=arm64-armv8a-linuxapp-gcc + sed -ri 's,(MVNETA_PMD=)n,\1y,' build/.config + make + +Usage Example +------------- + +MVNETA PMD requires extra out of tree kernel modules to function properly. +`musdk_uio` and `mv_neta_uio` sources are part of the MUSDK. Please consult +``doc/musdk_get_started.txt`` for the detailed build instructions. + +.. code-block:: console + + insmod musdk_uio.ko + insmod mv_neta_uio.ko + +Additionally interfaces used by DPDK application need to be put up: + +.. code-block:: console + + ip link set eth0 up + ip link set eth1 up + +In order to run testpmd example application following command can be used: + +.. code-block:: console + + ./testpmd --vdev=net_mvneta,iface=eth0,iface=eth1 -c 3 -- \ + -i --p 3 -a --txd 256 --rxd 128 --rxq=1 --txq=1 --nb-cores=1 + + +In order to run l2fwd example application following command can be used: + +.. code-block:: console + + ./l2fwd --vdev=net_mvneta,iface=eth0,iface=eth1 -c 3 -- -T 1 -p 3 diff --git a/doc/guides/nics/mvpp2.rst b/doc/guides/nics/mvpp2.rst index 0408752c..82b9383e 100644 --- a/doc/guides/nics/mvpp2.rst +++ b/doc/guides/nics/mvpp2.rst @@ -56,7 +56,7 @@ Features of the MVPP2 PMD are: - Speed capabilities - Link status -- Queue start/stop +- Tx Queue start/stop - MTU update - Jumbo frame - Promiscuous mode @@ -70,11 +70,13 @@ Features of the MVPP2 PMD are: - L4 checksum offload - Packet type parsing - Basic stats -- Extended stats -- QoS +- :ref:`Extended stats <extstats>` - RX flow control -- TX queue start/stop - +- Scattered TX frames +- :ref:`QoS <qossupport>` +- :ref:`Flow API <flowapi>` +- :ref:`Traffic metering and policing <mtrapi>` +- :ref:`Traffic Management API <tmapi>` Limitations ----------- @@ -88,6 +90,20 @@ Limitations functionality. Current workaround is to reset board so that PPv2 has a chance to start in a sane state. +- MUSDK architecture does not support changing configuration in run time. + All nessesary configurations should be done before first dev_start(). + +- RX queue start/stop is not supported. + +- Current implementation does not support replacement of buffers in the HW buffer pool + at run time, so it is responsibility of the application to ensure that MTU does not exceed the configured buffer size. + +- Configuring TX flow control currently is not supported. + +- In current implementation, mechanism for acknowledging transmitted packets (``tx_done_cleanup``) is not supported. + +- Running more than one DPDK-MUSDK application simultaneously is not supported. + Prerequisites ------------- @@ -96,19 +112,19 @@ Prerequisites .. code-block:: console - git clone https://github.com/MarvellEmbeddedProcessors/linux-marvell.git -b linux-4.4.52-armada-17.10 + git clone https://github.com/MarvellEmbeddedProcessors/linux-marvell.git -b linux-4.4.120-armada-18.09 - Out of tree `mvpp2x_sysfs` kernel module sources .. code-block:: console - git clone https://github.com/MarvellEmbeddedProcessors/mvpp2x-marvell.git -b mvpp2x-armada-17.10 + git clone https://github.com/MarvellEmbeddedProcessors/mvpp2x-marvell.git -b mvpp2x-armada-18.09 - MUSDK (Marvell User-Space SDK) sources .. code-block:: console - git clone https://github.com/MarvellEmbeddedProcessors/musdk-marvell.git -b musdk-armada-17.10 + git clone https://github.com/MarvellEmbeddedProcessors/musdk-marvell.git -b musdk-armada-18.09 MUSDK is a light-weight library that provides direct access to Marvell's PPv2 (Packet Processor v2). Alternatively prebuilt MUSDK library can be @@ -119,12 +135,6 @@ Prerequisites To get better understanding of the library one can consult documentation available in the ``doc`` top level directory of the MUSDK sources. - MUSDK must be configured with the following features: - - .. code-block:: console - - --enable-bpool-dma=64 - - DPDK environment Follow the DPDK :ref:`Getting Started Guide for Linux <linux_gsg>` to setup @@ -140,6 +150,95 @@ The following options can be modified in the ``config`` file. Toggle compilation of the librte mvpp2 driver. + .. Note:: + + When MVPP2 PMD is enabled ``CONFIG_RTE_LIBRTE_MVNETA_PMD`` must be disabled + + +Building DPDK +------------- + +Driver needs precompiled MUSDK library during compilation. + +.. code-block:: console + + export CROSS_COMPILE=<toolchain>/bin/aarch64-linux-gnu- + ./bootstrap + ./configure --host=aarch64-linux-gnu + make install + +MUSDK will be installed to `usr/local` under current directory. +For the detailed build instructions please consult ``doc/musdk_get_started.txt``. + +Before the DPDK build process the environmental variable ``LIBMUSDK_PATH`` with +the path to the MUSDK installation directory needs to be exported. + +For additional instructions regarding DPDK cross compilation please refer to :doc:`Cross compile DPDK for ARM64 <../linux_gsg/cross_build_dpdk_for_arm64>`. + +.. code-block:: console + + export LIBMUSDK_PATH=<musdk>/usr/local + export CROSS=<toolchain>/bin/aarch64-linux-gnu- + export RTE_KERNELDIR=<kernel-dir> + export RTE_TARGET=arm64-armv8a-linuxapp-gcc + + make config T=arm64-armv8a-linuxapp-gcc + sed -i "s/MVNETA_PMD=y/MVNETA_PMD=n/" build/.config + sed -i "s/MVPP2_PMD=n/MVPP2_PMD=y/" build/.config + make + +Usage Example +------------- + +MVPP2 PMD requires extra out of tree kernel modules to function properly. +`musdk_cma` sources are part of the MUSDK. Please consult +``doc/musdk_get_started.txt`` for the detailed build instructions. +For `mvpp2x_sysfs` please consult ``Documentation/pp22_sysfs.txt`` for the +detailed build instructions. + +.. code-block:: console + + insmod musdk_cma.ko + insmod mvpp2x_sysfs.ko + +Additionally interfaces used by DPDK application need to be put up: + +.. code-block:: console + + ip link set eth0 up + ip link set eth2 up + +In order to run testpmd example application following command can be used: + +.. code-block:: console + + ./testpmd --vdev=eth_mvpp2,iface=eth0,iface=eth2 -c 7 -- \ + --burst=128 --txd=2048 --rxd=1024 --rxq=2 --txq=2 --nb-cores=2 \ + -i -a --rss-udp + +.. _extstats: + +Extended stats +-------------- + +MVPP2 PMD supports the following extended statistics: + + - ``rx_bytes``: number of RX bytes + - ``rx_packets``: number of RX packets + - ``rx_unicast_packets``: number of RX unicast packets + - ``rx_errors``: number of RX MAC errors + - ``rx_fullq_dropped``: number of RX packets dropped due to full RX queue + - ``rx_bm_dropped``: number of RX packets dropped due to no available buffers in the HW pool + - ``rx_early_dropped``: number of RX packets that were early dropped + - ``rx_fifo_dropped``: number of RX packets dropped due to RX fifo overrun + - ``rx_cls_dropped``: number of RX packets dropped by classifier + - ``tx_bytes``: number of TX bytes + - ``tx_packets``: number of TX packets + - ``tx_unicast_packets``: number of TX unicast packets + - ``tx_errors``: number of TX MAC errors + + +.. _qossupport: QoS Configuration ----------------- @@ -152,20 +251,23 @@ Configuration syntax .. code-block:: console - [port <portnum> default] - default_tc = <default_tc> - mapping_priority = <mapping_priority> - policer_enable = <policer_enable> + [policer <policer_id>] token_unit = <token_unit> color = <color_mode> cir = <cir> ebs = <ebs> cbs = <cbs> + [port <portnum> default] + default_tc = <default_tc> + mapping_priority = <mapping_priority> + rate_limit_enable = <rate_limit_enable> rate_limit = <rate_limit> burst_size = <burst_size> + default_policer = <policer_id> + [port <portnum> tc <traffic_class>] rxq = <rx_queue_list> pcp = <pcp_list> @@ -201,7 +303,9 @@ Where: - ``<dscp_list>``: List of DSCP values to handle in particular TC (e.g. 0-12 32-48 63). -- ``<policer_enable>``: Enable ingress policer. +- ``<default_policer>``: Id of the policer configuration section to be used as default. + +- ``<policer_id>``: Id of the policer configuration section (0..31). - ``<token_unit>``: Policer token unit (`bytes` or `packets`). @@ -215,7 +319,7 @@ Where: - ``<default_color>``: Default color for specific tc. -- ``<rate_limit_enable>``: Enables per port or per txq rate limiting. +- ``<rate_limit_enable>``: Enables per port or per txq rate limiting (`0`/`1` to disable/enable). - ``<rate_limit>``: Committed information rate, in kilo bits per second. @@ -234,6 +338,13 @@ Configuration file example .. code-block:: console + [policer 0] + token_unit = bytes + color = blind + cir = 100000 + ebs = 64 + cbs = 64 + [port 0 default] default_tc = 0 mapping_priority = ip @@ -265,12 +376,7 @@ Configuration file example default_tc = 0 mapping_priority = vlan/ip - policer_enable = 1 - token_unit = bytes - color = blind - cir = 100000 - ebs = 64 - cbs = 64 + default_policer = 0 [port 1 tc 0] rxq = 0 @@ -297,38 +403,14 @@ Usage example ./testpmd --vdev=eth_mvpp2,iface=eth0,iface=eth2,cfg=/home/user/mrvl.conf \ -c 7 -- -i -a --disable-hw-vlan-strip --rxq=3 --txq=3 - -Building DPDK -------------- - -Driver needs precompiled MUSDK library during compilation. - -.. code-block:: console - - export CROSS_COMPILE=<toolchain>/bin/aarch64-linux-gnu- - ./bootstrap - ./configure --host=aarch64-linux-gnu --enable-bpool-dma=64 - make install - -MUSDK will be installed to `usr/local` under current directory. -For the detailed build instructions please consult ``doc/musdk_get_started.txt``. - -Before the DPDK build process the environmental variable ``LIBMUSDK_PATH`` with -the path to the MUSDK installation directory needs to be exported. - -.. code-block:: console - - export LIBMUSDK_PATH=<musdk>/usr/local - export CROSS=aarch64-linux-gnu- - make config T=arm64-armv8a-linuxapp-gcc - sed -ri 's,(MVPP2_PMD=)n,\1y,' build/.config - make +.. _flowapi: Flow API -------- PPv2 offers packet classification capabilities via classifier engine which can be configured via generic flow API offered by DPDK. +For an additional description please refer to DPDK :ref:`Generic flow API <Generic_flow_API>`. Supported flow actions ~~~~~~~~~~~~~~~~~~~~~~ @@ -489,32 +571,239 @@ Following limitations need to be taken into account while creating flow rules: For additional information about classifier please consult ``doc/musdk_cls_user_guide.txt``. -Usage Example -------------- +.. _mtrapi: -MVPP2 PMD requires extra out of tree kernel modules to function properly. -`musdk_uio` and `mv_pp_uio` sources are part of the MUSDK. Please consult -``doc/musdk_get_started.txt`` for the detailed build instructions. -For `mvpp2x_sysfs` please consult ``Documentation/pp22_sysfs.txt`` for the -detailed build instructions. +Traffic metering and policing +----------------------------- -.. code-block:: console +MVPP2 PMD supports DPDK traffic metering and policing that allows the following: - insmod musdk_uio.ko - insmod mv_pp_uio.ko - insmod mvpp2x_sysfs.ko +1. Meter ingress traffic. +2. Do policing. +3. Gather statistics. -Additionally interfaces used by DPDK application need to be put up: +For an additional description please refer to DPDK :doc:`Traffic Metering and Policing API <../prog_guide/traffic_metering_and_policing>`. -.. code-block:: console +The policer objects defined by this feature can work with the default policer defined via config file as described in :ref:`QoS Support <qossupport>`. - ip link set eth0 up - ip link set eth2 up +Limitations +~~~~~~~~~~~ -In order to run testpmd example application following command can be used: +The following capabilities are not supported: -.. code-block:: console +- MTR object meter DSCP table update +- MTR object policer action update +- MTR object enabled statistics - ./testpmd --vdev=eth_mvpp2,iface=eth0,iface=eth2 -c 7 -- \ - --burst=128 --txd=2048 --rxd=1024 --rxq=2 --txq=2 --nb-cores=2 \ - -i -a --rss-udp +Usage example +~~~~~~~~~~~~~ + +1. Run testpmd user app: + + .. code-block:: console + + ./testpmd --vdev=eth_mvpp2,iface=eth0,iface=eth2 -c 6 -- -i -p 3 -a --txd 1024 --rxd 1024 + +2. Create meter profile: + + .. code-block:: console + + testpmd> add port meter profile 0 0 srtcm_rfc2697 2000 256 256 + +3. Create meter: + + .. code-block:: console + + testpmd> create port meter 0 0 0 yes d d d 0 1 0 + +4. Create flow rule witch meter attached: + + .. code-block:: console + + testpmd> flow create 0 ingress pattern ipv4 src is 10.10.10.1 / end actions meter mtr_id 0 / end + +For a detailed usage description please refer to "Traffic Metering and Policing" section in DPDK :doc:`Testpmd Runtime Functions <../testpmd_app_ug/testpmd_funcs>`. + + + +.. _tmapi: + +Traffic Management API +---------------------- + +MVPP2 PMD supports generic DPDK Traffic Management API which allows to +configure the following features: + +1. Hierarchical scheduling +2. Traffic shaping +3. Congestion management +4. Packet marking + +Internally TM is represented by a hierarchy (tree) of nodes. +Node which has a parent is called a leaf whereas node without +parent is called a non-leaf (root). +MVPP2 PMD supports two level hierarchy where level 0 represents ports and level 1 represents tx queues of a given port. + +.. figure:: img/mvpp2_tm.svg + +Nodes hold following types of settings: + +- for egress scheduler configuration: weight +- for egress rate limiter: private shaper +- bitmask indicating which statistics counters will be read + +Hierarchy is always constructed from the top, i.e first a root node is added +then some number of leaf nodes. Number of leaf nodes cannot exceed number +of configured tx queues. + +After hierarchy is complete it can be committed. + + +For an additional description please refer to DPDK :doc:`Traffic Management API <../prog_guide/traffic_management>`. + +Limitations +~~~~~~~~~~~ + +The following capabilities are not supported: + +- Traffic manager WRED profile and WRED context +- Traffic manager shared shaper update +- Traffic manager packet marking +- Maximum number of levels in hierarchy is 2 +- Currently dynamic change of a hierarchy is not supported + +Usage example +~~~~~~~~~~~~~ + +For a detailed usage description please refer to "Traffic Management" section in DPDK :doc:`Testpmd Runtime Functions <../testpmd_app_ug/testpmd_funcs>`. + +1. Run testpmd as follows: + + .. code-block:: console + + ./testpmd --vdev=net_mrvl,iface=eth0,iface=eth2,cfg=./qos_config -c 7 -- \ + -i -p 3 --disable-hw-vlan-strip --rxq 3 --txq 3 --txd 1024 --rxd 1024 + +2. Stop all ports: + + .. code-block:: console + + testpmd> port stop all + +3. Add shaper profile: + + .. code-block:: console + + testpmd> add port tm node shaper profile 0 0 900000 70000 0 + + Parameters have following meaning:: + + 0 - Id of a port. + 0 - Id of a new shaper profile. + 900000 - Shaper rate in bytes/s. + 70000 - Bucket size in bytes. + 0 - Packet length adjustment - ignored. + +4. Add non-leaf node for port 0: + + .. code-block:: console + + testpmd> add port tm nonleaf node 0 3 -1 0 0 0 0 0 1 3 0 + + Parameters have following meaning:: + + 0 - Id of a port + 3 - Id of a new node. + -1 - Indicate that root does not have a parent. + 0 - Priority of the node. + 0 - Weight of the node. + 0 - Id of a level. Since this is a root 0 is passed. + 0 - Id of the shaper profile. + 0 - Number of SP priorities. + 3 - Enable statistics for both number of transmitted packets and bytes. + 0 - Number of shared shapers. + +5. Add leaf node for tx queue 0: + + .. code-block:: console + + testpmd> add port tm leaf node 0 0 3 0 30 1 -1 0 0 1 0 + + Parameters have following meaning:: + + 0 - Id of a port. + 0 - Id of a new node. + 3 - Id of the parent node. + 0 - Priority of a node. + 30 - WRR weight. + 1 - Id of a level. Since this is a leaf node 1 is passed. + -1 - Id of a shaper. -1 indicates that shaper is not attached. + 0 - Congestion management is not supported. + 0 - Congestion management is not supported. + 1 - Enable statistics counter for number of transmitted packets. + 0 - Number of shared shapers. + +6. Add leaf node for tx queue 1: + + .. code-block:: console + + testpmd> add port tm leaf node 0 1 3 0 60 1 -1 0 0 1 0 + + Parameters have following meaning:: + + 0 - Id of a port. + 1 - Id of a new node. + 3 - Id of the parent node. + 0 - Priority of a node. + 60 - WRR weight. + 1 - Id of a level. Since this is a leaf node 1 is passed. + -1 - Id of a shaper. -1 indicates that shaper is not attached. + 0 - Congestion management is not supported. + 0 - Congestion management is not supported. + 1 - Enable statistics counter for number of transmitted packets. + 0 - Number of shared shapers. + +7. Add leaf node for tx queue 2: + + .. code-block:: console + + testpmd> add port tm leaf node 0 2 3 0 99 1 -1 0 0 1 0 + + Parameters have following meaning:: + + 0 - Id of a port. + 2 - Id of a new node. + 3 - Id of the parent node. + 0 - Priority of a node. + 99 - WRR weight. + 1 - Id of a level. Since this is a leaf node 1 is passed. + -1 - Id of a shaper. -1 indicates that shaper is not attached. + 0 - Congestion management is not supported. + 0 - Congestion management is not supported. + 1 - Enable statistics counter for number of transmitted packets. + 0 - Number of shared shapers. + +8. Commit hierarchy: + + .. code-block:: console + + testpmd> port tm hierarchy commit 0 no + + Parameters have following meaning:: + + 0 - Id of a port. + no - Do not flush TM hierarchy if commit fails. + +9. Start all ports + + .. code-block:: console + + testpmd> port start all + + + +10. Enable forwarding + + .. code-block:: console + + testpmd> start diff --git a/doc/guides/nics/netvsc.rst b/doc/guides/nics/netvsc.rst index 345f393c..87fabf5b 100644 --- a/doc/guides/nics/netvsc.rst +++ b/doc/guides/nics/netvsc.rst @@ -28,19 +28,16 @@ In this release, the hyper PMD driver provides the basic functionality of packet * VLAN tags are always stripped and presented in mbuf tci field. -* The Hyper-V driver does not use or support Link State or Rx interrupt. +* The Hyper-V driver does not use or support interrupts. Link state change + callback is done via change events in the packet ring. * The maximum number of queues is limited by the host (currently 64). When used with 4.16 kernel only a single queue is available. -.. note:: - This driver is intended for use with **Hyper-V only** and is - not recommended for use on Azure because accelerated Networking - (SR-IOV) is not supported. - - On Azure, use the :doc:`vdev_netvsc` which - automatically configures the necessary TAP and failsave drivers. - +* This driver supports SR-IOV network acceleration. + If SR-IOV is enabled then the driver will transparently manage the interface, + and send and receive packets using the VF path. + The VDEV_NETVSC and FAILSAFE drivers are *not* used when using netvsc PMD. Installation ------------ @@ -103,3 +100,19 @@ The following prerequisites apply: * Linux kernel support for UIO on vmbus is done with the uio_hv_generic driver. Full support of multiple queues requires the 4.17 kernel. It is possible to use the netvsc PMD with 4.16 kernel but it is limited to a single queue. + + +Netvsc PMD arguments +-------------------- + +The user can specify below argument in devargs. + +#. ``latency``: + + A netvsc device uses a mailbox page to indicate to the host that there + is something in the transmit queue. The host scans this page at a + periodic interval. This parameter allows adjusting the value that + is used by the host. Smaller values improve transmit latency, and larger + values save CPU cycles. This parameter is in microseconds. + If the value is too large or too small it will be + ignored by the host. (Default: 50) diff --git a/doc/guides/nics/octeontx.rst b/doc/guides/nics/octeontx.rst index f8eaaa63..f8111d3c 100644 --- a/doc/guides/nics/octeontx.rst +++ b/doc/guides/nics/octeontx.rst @@ -1,11 +1,11 @@ .. SPDX-License-Identifier: BSD-3-Clause Copyright(c) 2017 Cavium, Inc -OCTEONTX Poll Mode driver -========================= +OCTEON TX Poll Mode driver +========================== -The OCTEONTX ETHDEV PMD (**librte_pmd_octeontx**) provides poll mode ethdev -driver support for the inbuilt network device found in the **Cavium OCTEONTX** +The OCTEON TX ETHDEV PMD (**librte_pmd_octeontx**) provides poll mode ethdev +driver support for the inbuilt network device found in the **Cavium OCTEON TX** SoC family as well as their virtual functions (VF) in SR-IOV context. More information can be found at `Cavium, Inc Official Website @@ -14,7 +14,7 @@ More information can be found at `Cavium, Inc Official Website Features -------- -Features of the OCTEONTX Ethdev PMD are: +Features of the OCTEON TX Ethdev PMD are: - Packet type information - Promiscuous mode @@ -26,8 +26,8 @@ Features of the OCTEONTX Ethdev PMD are: - Lock-free Tx queue - HW offloaded `ethdev Rx queue` to `eventdev event queue` packet injection -Supported OCTEONTX SoCs ------------------------ +Supported OCTEON TX SoCs +------------------------ - CN83xx @@ -65,7 +65,7 @@ Driver compilation and testing Refer to the document :ref:`compiling and testing a PMD for a NIC <pmd_build_and_test>` for details. -To compile the OCTEONTX PMD for Linux arm64 gcc target, run the +To compile the OCTEON TX PMD for Linux arm64 gcc target, run the following ``make`` command: .. code-block:: console @@ -122,7 +122,7 @@ following ``make`` command: Initialization -------------- -The octeontx ethdev pmd is exposed as a vdev device which consists of a set +The OCTEON TX ethdev pmd is exposed as a vdev device which consists of a set of PKI and PKO PCIe VF devices. On EAL initialization, PKI/PKO PCIe VF devices will be probed and then the vdev device can be created from the application code, or from the EAL command line based on @@ -156,21 +156,21 @@ Limitations ``octeontx_fpavf`` external mempool handler dependency ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -The OCTEONTX SoC family NIC has inbuilt HW assisted external mempool manager. +The OCTEON TX SoC family NIC has inbuilt HW assisted external mempool manager. This driver will only work with ``octeontx_fpavf`` external mempool handler as it is the most performance effective way for packet allocation and Tx buffer -recycling on OCTEONTX SoC platform. +recycling on OCTEON TX SoC platform. CRC striping ~~~~~~~~~~~~ -The OCTEONTX SoC family NICs strip the CRC for every packets coming into the +The OCTEON TX SoC family NICs strip the CRC for every packets coming into the host interface irrespective of the offload configuration. Maximum packet length ~~~~~~~~~~~~~~~~~~~~~ -The OCTEONTX SoC family NICs support a maximum of a 32K jumbo frame. The value +The OCTEON TX SoC family NICs support a maximum of a 32K jumbo frame. The value is fixed and cannot be changed. So, even when the ``rxmode.max_rx_pkt_len`` member of ``struct rte_eth_conf`` is set to a value lower than 32k, frames up to 32k bytes can still reach the host interface. diff --git a/doc/guides/nics/pcap_ring.rst b/doc/guides/nics/pcap_ring.rst index 879e5430..c1ef9196 100644 --- a/doc/guides/nics/pcap_ring.rst +++ b/doc/guides/nics/pcap_ring.rst @@ -96,6 +96,16 @@ The different stream types are: iface=eth0 +Runtime Config Options +^^^^^^^^^^^^^^^^^^^^^^ + +- Use PCAP interface physical MAC + + In case ``iface=`` configuration is set, user may want to use the selected interface's physical MAC + address. This can be done with a ``devarg`` ``phy_mac``, for example:: + + --vdev 'net_pcap0,iface=eth0,phy_mac=1' + Examples of Usage ^^^^^^^^^^^^^^^^^ diff --git a/doc/guides/nics/sfc_efx.rst b/doc/guides/nics/sfc_efx.rst index 63939ec8..40065284 100644 --- a/doc/guides/nics/sfc_efx.rst +++ b/doc/guides/nics/sfc_efx.rst @@ -240,6 +240,10 @@ Supported NICs - Solarflare X2522 Dual Port SFP28 10/25GbE Adapter + - Solarflare X2541 Single Port QSFP28 10/25G/100G Adapter + + - Solarflare X2542 Dual Port QSFP28 10/25G/100G Adapter + - Solarflare Flareon [Ultra] Server Adapters: - Solarflare SFN8522 Dual Port SFP+ Server Adapter @@ -318,7 +322,7 @@ boolean parameters value. **efx** chooses libefx-based datapath which supports Rx scatter. **ef10** chooses EF10 (SFN7xxx, SFN8xxx, X2xxx) native datapath which is more efficient than libefx-based and provides richer packet type - classification, but lacks Rx scatter support. + classification. **ef10_esps** chooses SFNX2xxx equal stride packed stream datapath which may be used on DPDK firmware variant only (see notes about its limitations above). @@ -333,8 +337,7 @@ boolean parameters value. Mbuf segments may come from different mempools, and mbuf reference counters are treated responsibly. **ef10** chooses EF10 (SFN7xxx, SFN8xxx, X2xxx) native datapath which is - more efficient than libefx-based but has no VLAN insertion and TSO - support yet. + more efficient than libefx-based but has no VLAN insertion support yet. Mbuf segments may come from different mempools, and mbuf reference counters are treated responsibly. **ef10_simple** chooses EF10 (SFN7xxx, SFN8xxx, X2xxx) native datapath which diff --git a/doc/guides/nics/softnic.rst b/doc/guides/nics/softnic.rst index 6c2287a1..32a9cf22 100644 --- a/doc/guides/nics/softnic.rst +++ b/doc/guides/nics/softnic.rst @@ -248,3 +248,123 @@ command description provided in `softnic/rte_eth_softnic_cli.c`. thread 1 pipeline RX enable (Soft NIC rx pipeline enable on cpu thread id 1) thread 1 pipeline TX enable (Soft NIC tx pipeline enable on cpu thread id 1) + +QoS API Support: +---------------- + +SoftNIC PMD implements ethdev traffic management APIs ``rte_tm.h`` that +allow building and committing traffic manager hierarchy, configuring hierarchy +nodes of the Quality of Service (QoS) scheduler supported by DPDK librte_sched +library. Furthermore, APIs for run-time update to the traffic manager hierarchy +are supported by PMD. + +SoftNIC PMD also implements ethdev traffic metering and policing APIs +``rte_mtr.h`` that enables metering and marking of the packets with the +appropriate color (green, yellow or red), according to the traffic metering +algorithm. For the meter output color, policer actions like +`keep the packet color same`, `change the packet color` or `drop the packet` +can be configured. + +.. Note:: + + The SoftNIC does not support the meter object shared by several flows, + thus only supports creating meter object private to the flow. Once meter + object is successfully created, it can be linked to the specific flow by + specifying the ``meter`` flow action in the flow rule. + +Flow API support: +----------------- + +The SoftNIC PMD implements ethdev flow APIs ``rte_flow.h`` that allow validating +flow rules, adding flow rules to the SoftNIC pipeline as table rules, deleting +and querying the flow rules. The PMD provides new cli command for creating the +flow group and their mapping to the SoftNIC pipeline and table. This cli should +be configured as part of firmware file. + + .. code-block:: console + + flowapi map group <group_id> ingress | egress pipeline <pipeline_name> \ + table <table_id> + +From the flow attributes of the flow, PMD uses the group id to get the mapped +pipeline and table. PMD supports number of flow actions such as +``JMP, QUEUE, RSS, DROP, COUNT, METER, VXLAN`` etc. + +.. Note:: + + The flow must have one terminating actions i.e. + ``JMP or RSS or QUEUE or DROP``. For the count and drop actions the + underlying PMD doesn't support the functionality yet. So it is not + recommended for use. + +The flow API can be tested with the help of testpmd application. The SoftNIC +firmware specifies CLI commands for port configuration, pipeline creation, +action profile creation and table creation. Once application gets initialized, +the flow rules can be added through the testpmd CLI. +The PMD will translate the flow rules to the SoftNIC pipeline tables rules. + +Example: +~~~~~~~~ +Example demonstrates the flow queue action using the SoftNIC firmware and testpmd +commands. + +* Prepare SoftNIC firmware + + .. code-block:: console + + link LINK0 dev 0000:83:00.0 + link LINK1 dev 0000:81:00.0 + pipeline RX period 10 offset_port_id 0 + pipeline RX port in bsz 32 link LINK0 rxq 0 + pipeline RX port in bsz 32 link LINK1 rxq 0 + pipeline RX port out bsz 32 swq RXQ0 + pipeline RX port out bsz 32 swq RXQ1 + table action profile AP0 ipv4 offset 278 fwd + pipeline RX table match hash ext key 16 mask + 00FF0000FFFFFFFFFFFFFFFFFFFFFFFF \ + offset 278 buckets 16K size 65K action AP0 + pipeline RX port in 0 table 0 + pipeline RX port in 1 table 0 + flowapi map group 0 ingress pipeline RX table 0 + pipeline TX period 10 offset_port_id 0 + pipeline TX port in bsz 32 swq TXQ0 + pipeline TX port in bsz 32 swq TXQ1 + pipeline TX port out bsz 32 link LINK0 txq 0 + pipeline TX port out bsz 32 link LINK1 txq 0 + pipeline TX table match hash ext key 16 mask + 00FF0000FFFFFFFFFFFFFFFFFFFFFFFF \ + offset 278 buckets 16K size 65K action AP0 + pipeline TX port in 0 table 0 + pipeline TX port in 1 table 0 + pipeline TX table 0 rule add match hash ipv4_5tuple + 1.10.11.12 2.20.21.22 100 200 6 action fwd port 0 + pipeline TX table 0 rule add match hash ipv4_5tuple + 1.10.11.13 2.20.21.23 100 200 6 action fwd port 1 + thread 25 pipeline RX enable + thread 25 pipeline TX enable + +* Run testpmd: + + .. code-block:: console + + ./x86_64-native-linuxapp-gcc/app/testpmd -l 23-25 -n 4 \ + --vdev 'net_softnic0, \ + firmware=./drivers/net/softnic/ \ + firmware.cli, \ + cpu_id=1,conn_port=8086' -- \ + -i --forward-mode=softnic --rxq=2, \ + --txq=2, --disable-rss --portmask=0x4 + +* Configure flow rules on softnic: + + .. code-block:: console + + flow create 2 group 0 ingress pattern eth / ipv4 proto mask 255 src \ + mask 255.255.255.255 dst mask 255.255.255.255 src spec + 1.10.11.12 dst spec 2.20.21.22 proto spec 6 / tcp src mask 65535 \ + dst mask 65535 src spec 100 dst spec 200 / end actions queue \ + index 0 / end + flow create 2 group 0 ingress pattern eth / ipv4 proto mask 255 src \ + mask 255.255.255.255 dst mask 255.255.255.255 src spec 1.10.11.13 \ + dst spec 2.20.21.23 proto spec 6 / tcp src mask 65535 dst mask \ + 65535 src spec 100 dst spec 200 / end actions queue index 1 / end diff --git a/doc/guides/nics/tap.rst b/doc/guides/nics/tap.rst index 27148681..9a3d7b34 100644 --- a/doc/guides/nics/tap.rst +++ b/doc/guides/nics/tap.rst @@ -152,6 +152,22 @@ Distribute IPv4 TCP packets using RSS to a given MAC address over queues 0-3:: testpmd> flow create 0 priority 4 ingress pattern eth dst is 0a:0b:0c:0d:0e:0f \ / ipv4 / tcp / end actions rss queues 0 1 2 3 end / end +Multi-process sharing +--------------------- + +It is possible to attach an existing TAP device in a secondary process, +by declaring it as a vdev with the same name as in the primary process, +and without any parameter. + +The port attached in a secondary process will give access to the +statistics and the queues. +Therefore it can be used for monitoring or Rx/Tx processing. + +The IPC synchronization of Rx/Tx queues is currently limited: + + - Maximum 8 queues shared + - Synchronized on probing, but not on later port update + Example ------- diff --git a/doc/guides/nics/vhost.rst b/doc/guides/nics/vhost.rst index 4f7ae899..23f2e87a 100644 --- a/doc/guides/nics/vhost.rst +++ b/doc/guides/nics/vhost.rst @@ -71,6 +71,11 @@ The user can specify below arguments in `--vdev` option. It is used to enable iommu support in vhost library. (Default: 0 (disabled)) +#. ``postcopy-support``: + + It is used to enable postcopy live-migration support in vhost library. + (Default: 0 (disabled)) + Vhost PMD event handling ------------------------ diff --git a/doc/guides/nics/virtio.rst b/doc/guides/nics/virtio.rst index 7c099fb7..2ae875cb 100644 --- a/doc/guides/nics/virtio.rst +++ b/doc/guides/nics/virtio.rst @@ -47,7 +47,7 @@ In this release, the virtio PMD driver provides the basic functionality of packe * The descriptor number for the Rx/Tx queue is hard-coded to be 256 by qemu 2.7 and below. If given a different descriptor number by the upper application, the virtio PMD generates a warning and fall back to the hard-coded value. - Rx queue size can be configureable and up to 1024 since qemu 2.8 and above. Rx queue size is 256 + Rx queue size can be configurable and up to 1024 since qemu 2.8 and above. Rx queue size is 256 by default. Tx queue size is still hard-coded to be 256. * Features of mac/vlan filter are supported, negotiation with vhost/backend are needed to support them. diff --git a/doc/guides/platform/octeontx.rst b/doc/guides/platform/octeontx.rst index b0a99c38..9f75d2a8 100644 --- a/doc/guides/platform/octeontx.rst +++ b/doc/guides/platform/octeontx.rst @@ -1,12 +1,12 @@ .. SPDX-License-Identifier: BSD-3-Clause Copyright(c) 2017 Cavium, Inc -OCTEONTX Board Support Package -============================== +OCTEON TX Board Support Package +=============================== -This doc has information about steps to setup octeontx platform +This doc has information about steps to setup OCTEON TX platform and information about common offload hw block drivers of -**Cavium OCTEONTX** SoC family. +**Cavium OCTEON TX** SoC family. More information about SoC can be found at `Cavium, Inc Official Website @@ -27,11 +27,11 @@ Steps To Setup Platform ----------------------- There are three main pre-prerequisites for setting up Platform drivers on -OCTEONTX compatible board: +OCTEON TX compatible board: -1. **OCTEONTX Linux kernel PF driver for Network acceleration HW blocks** +1. **OCTEON TX Linux kernel PF driver for Network acceleration HW blocks** - The OCTEONTX Linux kernel drivers (includes the required PF driver for the + The OCTEON TX Linux kernel drivers (includes the required PF driver for the Platform drivers) are available on Github at `octeontx-kmod <https://github.com/caviumnetworks/octeontx-kmod>`_ along with build, install and dpdk usage instructions. @@ -48,7 +48,7 @@ OCTEONTX compatible board: As an alternative method, Platform drivers can also be executed using images provided as part of SDK from Cavium. The SDK includes all the above prerequisites necessary - to bring up a OCTEONTX board. + to bring up a OCTEON TX board. SDK and related information can be obtained from: `Cavium support site <https://support.cavium.com/>`_. diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/prog_guide/env_abstraction_layer.rst index d362c920..4f8612a2 100644 --- a/doc/guides/prog_guide/env_abstraction_layer.rst +++ b/doc/guides/prog_guide/env_abstraction_layer.rst @@ -213,6 +213,43 @@ Normally, these options do not need to be changed. can later be mapped into that preallocated VA space (if dynamic memory mode is enabled), and can optionally be mapped into it at startup. +Support for Externally Allocated Memory +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It is possible to use externally allocated memory in DPDK, using a set of malloc +heap API's. Support for externally allocated memory is implemented through +overloading the socket ID - externally allocated heaps will have socket ID's +that would be considered invalid under normal circumstances. Requesting an +allocation to take place from a specified externally allocated memory is a +matter of supplying the correct socket ID to DPDK allocator, either directly +(e.g. through a call to ``rte_malloc``) or indirectly (through data +structure-specific allocation API's such as ``rte_ring_create``). + +Since there is no way DPDK can verify whether memory are is available or valid, +this responsibility falls on the shoulders of the user. All multiprocess +synchronization is also user's responsibility, as well as ensuring that all +calls to add/attach/detach/remove memory are done in the correct order. It is +not required to attach to a memory area in all processes - only attach to memory +areas as needed. + +The expected workflow is as follows: + +* Get a pointer to memory area +* Create a named heap +* Add memory area(s) to the heap + - If IOVA table is not specified, IOVA addresses will be assumed to be + unavailable, and DMA mappings will not be performed + - Other processes must attach to the memory area before they can use it +* Get socket ID used for the heap +* Use normal DPDK allocation procedures, using supplied socket ID +* If memory area is no longer needed, it can be removed from the heap + - Other processes must detach from this memory area before it can be removed +* If heap is no longer needed, remove it + - Socket ID will become invalid and will not be reused + +For more information, please refer to ``rte_malloc`` API documentation, +specifically the ``rte_malloc_heap_*`` family of function calls. + PCI Access ~~~~~~~~~~ @@ -321,6 +358,14 @@ Misc Functions Locks and atomic operations are per-architecture (i686 and x86_64). +IOVA Mode Configuration +~~~~~~~~~~~~~~~~~~~~~~~ + +Auto detection of the IOVA mode, based on probing the bus and IOMMU configuration, may not report +the desired addressing mode when virtual devices that are not directly attached to the bus are present. +To facilitate forcing the IOVA mode to a specific value the EAL command line option ``--iova-mode`` can +be used to select either physical addressing('pa') or virtual addressing('va'). + Memory Segments and Memory Zones (memzone) ------------------------------------------ diff --git a/doc/guides/prog_guide/event_ethernet_tx_adapter.rst b/doc/guides/prog_guide/event_ethernet_tx_adapter.rst new file mode 100644 index 00000000..192f9e1c --- /dev/null +++ b/doc/guides/prog_guide/event_ethernet_tx_adapter.rst @@ -0,0 +1,165 @@ +.. SPDX-License-Identifier: BSD-3-Clause + Copyright(c) 2017 Intel Corporation. + +Event Ethernet Tx Adapter Library +================================= + +The DPDK Eventdev API allows the application to use an event driven programming +model for packet processing in which the event device distributes events +referencing packets to the application cores in a dynamic load balanced fashion +while handling atomicity and packet ordering. Event adapters provide the interface +between the ethernet, crypto and timer devices and the event device. Event adapter +APIs enable common application code by abstracting PMD specific capabilities. +The Event ethernet Tx adapter provides configuration and data path APIs for the +transmit stage of the application allowing the same application code to use eventdev +PMD support or in its absence, a common implementation. + +In the common implementation, the application enqueues mbufs to the adapter +which runs as a rte_service function. The service function dequeues events +from its event port and transmits the mbufs referenced by these events. + + +API Walk-through +---------------- + +This section will introduce the reader to the adapter API. The +application has to first instantiate an adapter which is associated with +a single eventdev, next the adapter instance is configured with Tx queues, +finally the adapter is started and the application can start enqueuing mbufs +to it. + +Creating an Adapter Instance +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +An adapter instance is created using ``rte_event_eth_tx_adapter_create()``. This +function is passed the event device to be associated with the adapter and port +configuration for the adapter to setup an event port if the adapter needs to use +a service function. + +If the application desires to have finer control of eventdev port configuration, +it can use the ``rte_event_eth_tx_adapter_create_ext()`` function. The +``rte_event_eth_tx_adapter_create_ext()`` function is passed a callback function. +The callback function is invoked if the adapter needs to use a service function +and needs to create an event port for it. The callback is expected to fill the +``struct rte_event_eth_tx_adapter_conf`` structure passed to it. + +.. code-block:: c + + struct rte_event_dev_info dev_info; + struct rte_event_port_conf tx_p_conf = {0}; + + err = rte_event_dev_info_get(id, &dev_info); + + tx_p_conf.new_event_threshold = dev_info.max_num_events; + tx_p_conf.dequeue_depth = dev_info.max_event_port_dequeue_depth; + tx_p_conf.enqueue_depth = dev_info.max_event_port_enqueue_depth; + + err = rte_event_eth_tx_adapter_create(id, dev_id, &tx_p_conf); + +Adding Tx Queues to the Adapter Instance +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Ethdev Tx queues are added to the instance using the +``rte_event_eth_tx_adapter_queue_add()`` function. A queue value +of -1 is used to indicate all queues within a device. + +.. code-block:: c + + int err = rte_event_eth_tx_adapter_queue_add(id, + eth_dev_id, + q); + +Querying Adapter Capabilities +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The ``rte_event_eth_tx_adapter_caps_get()`` function allows +the application to query the adapter capabilities for an eventdev and ethdev +combination. Currently, the only capability flag defined is +``RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT``, the application can +query this flag to determine if a service function is associated with the +adapter and retrieve its service identifier using the +``rte_event_eth_tx_adapter_service_id_get()`` API. + + +.. code-block:: c + + int err = rte_event_eth_tx_adapter_caps_get(dev_id, eth_dev_id, &cap); + + if (!(cap & RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT)) + err = rte_event_eth_tx_adapter_service_id_get(id, &service_id); + +Linking a Queue to the Adapter's Event Port +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +If the adapter uses a service function as described in the previous section, the +application is required to link a queue to the adapter's event port. The adapter's +event port can be obtained using the ``rte_event_eth_tx_adapter_event_port_get()`` +function. The queue can be configured with the ``RTE_EVENT_QUEUE_CFG_SINGLE_LINK`` +since it is linked to a single event port. + +Configuring the Service Function +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +If the adapter uses a service function, the application can assign +a service core to the service function as shown below. + +.. code-block:: c + + if (rte_event_eth_tx_adapter_service_id_get(id, &service_id) == 0) + rte_service_map_lcore_set(service_id, TX_CORE_ID); + +Starting the Adapter Instance +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The application calls ``rte_event_eth_tx_adapter_start()`` to start the adapter. +This function calls the start callback of the eventdev PMD if supported, +and the ``rte_service_run_state_set()`` to enable the service function if one exists. + +Enqueuing Packets to the Adapter +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The application needs to notify the adapter about the transmit port and queue used +to send the packet. The transmit port is set in the ``struct rte mbuf::port`` field +and the transmit queue is set using the ``rte_event_eth_tx_adapter_txq_set()`` +function. + +If the eventdev PMD supports the ``RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT`` +capability for a given ethernet device, the application should use the +``rte_event_eth_tx_adapter_enqueue()`` function to enqueue packets to the adapter. + +If the adapter uses a service function for the ethernet device then the application +should use the ``rte_event_enqueue_burst()`` function. + +.. code-block:: c + + struct rte_event event; + + if (cap & RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT) { + + event.mbuf = m; + + m->port = tx_port; + rte_event_eth_tx_adapter_txq_set(m, tx_queue_id); + + rte_event_eth_tx_adapter_enqueue(dev_id, ev_port, &event, 1); + } else { + + event.queue_id = qid; /* event queue linked to adapter port */ + event.op = RTE_EVENT_OP_NEW; + event.event_type = RTE_EVENT_TYPE_CPU; + event.sched_type = RTE_SCHED_TYPE_ATOMIC; + event.mbuf = m; + + m->port = tx_port; + rte_event_eth_tx_adapter_txq_set(m, tx_queue_id); + + rte_event_enqueue_burst(dev_id, ev_port, &event, 1); + } + +Getting Adapter Statistics +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The ``rte_event_eth_tx_adapter_stats_get()`` function reports counters defined +in struct ``rte_event_eth_tx_adapter_stats``. The counter values are the sum of +the counts from the eventdev PMD callback if the callback is supported, and +the counts maintained by the service function, if one exists. diff --git a/doc/guides/prog_guide/hash_lib.rst b/doc/guides/prog_guide/hash_lib.rst index 76a1f323..f5beec1d 100644 --- a/doc/guides/prog_guide/hash_lib.rst +++ b/doc/guides/prog_guide/hash_lib.rst @@ -1,5 +1,6 @@ .. SPDX-License-Identifier: BSD-3-Clause Copyright(c) 2010-2015 Intel Corporation. + Copyright(c) 2018 Arm Limited. .. _Hash_Library: @@ -38,7 +39,7 @@ The main methods exported by the hash are: * Lookup for entry with key: The key is provided as input. If an entry with the specified key is found in the hash (lookup hit), then the position of the entry is returned, otherwise (lookup miss) a negative value is returned. -Apart from these method explained above, the API allows the user three more options: +Apart from these methods explained above, the API provides the user with few more options: * Add / lookup / delete with key and precomputed hash: Both the key and its precomputed hash are provided as input. This allows the user to perform these operations faster, as hash is already computed. @@ -48,6 +49,9 @@ Apart from these method explained above, the API allows the user three more opti * Combination of the two options above: User can provide key, precomputed hash and data. +* Ability to not free the position of the entry in the hash upon calling delete. This is useful for multi-threaded scenarios where + readers continue to use the position even after the entry is deleted. + Also, the API contains a method to allow the user to look up entries in bursts, achieving higher performance than looking up individual entries, as the function prefetches next entries at the time it is operating with the first ones, which reduces significantly the impact of the necessary memory accesses. @@ -83,13 +87,20 @@ For concurrent writes, and concurrent reads and writes the following flag values Key add, delete, and table reset are protected from other writer threads. With only this flag set, readers are not protected from ongoing writes. * If the read/write concurrency (RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY) is set, multithread read/write operation is safe - (i.e., no need to stop the readers from accessing the hash table until writers finish their updates. Reads and writes can operate table concurrently). + (i.e., application does not need to stop the readers from accessing the hash table until writers finish their updates. Readers and writers can operate on the table concurrently). + The library uses a reader-writer lock to provide the concurrency. * In addition to these two flag values, if the transactional memory flag (RTE_HASH_EXTRA_FLAGS_TRANS_MEM_SUPPORT) is also set, - hardware transactional memory will be used to guarantee the thread safety as long as it is supported by the hardware (for example the Intel® TSX support). + the reader-writer lock will use hardware transactional memory to guarantee thread safety as long as it is supported by the hardware (for example the Intel® TSX support). + If the platform supports Intel® TSX, it is advised to set the transactional memory flag, as this will speed up concurrent table operations. + Otherwise concurrent operations will be slower because of the overhead associated with the software locking mechanisms. + +* If lock free read/write concurrency (RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY_LF) is set, read/write concurrency is provided without using reader-writer lock. + For platforms (ex: current Arm based platforms), that do not support transactional memory, it is advised to set this flag to achieve greater scalability in performance. -If the platform supports Intel® TSX, it is advised to set the transactional memory flag, as this will speed up concurrent table operations. -Otherwise concurrent operations will be slower because of the overhead associated with the software locking mechanisms. +* If, do not free on delete (RTE_HASH_EXTRA_FLAGS_NO_FREE_ON_DEL) flag is set, the position of the entry in the hash is not freed upon calling delete. This flag is enabled + by default when lock free read/write concurrency is set. The application should free the position after all the readers have stopped referencing the position. + Where required, the application can make use of RCU mechanisms to determine when the readers have stopped referencing the position. Implementation Details ---------------------- @@ -148,6 +159,14 @@ key is considered not able to be stored. With random keys, this method allows the user to get around 90% of the table utilization, without having to drop any stored entry (LRU) or allocate more memory (extended buckets). + +Example of deletion: + +Similar to lookup, the key is searched in its primary and secondary buckets. If the key is found, the bucket +entry is marked as an empty slot. If the hash table was configured with 'no free on delete' or 'lock free read/write concurrency', +the position of the key is not freed. It is the responsibility of the user to free the position while making sure that +readers are not referencing the position anymore. + Entry distribution in hash table -------------------------------- @@ -240,6 +259,10 @@ The flow table operations on the application side are described below: * Delete flow: Delete the flow key from the hash. If the returned position is valid, use it to access the flow entry in the flow table to invalidate the information associated with the flow. +* Free flow: Free flow key position. If 'no free on delete' or 'lock-free read/write concurrency' flags are set, + wait till the readers are not referencing the position returned during add/delete flow and then free the position. + RCU mechanisms can be used to find out when the readers are not referencing the position anymore. + * Lookup flow: Lookup for the flow key in the hash. If the returned position is valid (flow lookup hit), use the returned position to access the flow entry in the flow table. Otherwise (flow lookup miss) there is no flow registered for the current packet. diff --git a/doc/guides/prog_guide/index.rst b/doc/guides/prog_guide/index.rst index 3b920e53..2086e244 100644 --- a/doc/guides/prog_guide/index.rst +++ b/doc/guides/prog_guide/index.rst @@ -44,6 +44,7 @@ Programmer's Guide thread_safety_dpdk_functions eventdev event_ethernet_rx_adapter + event_ethernet_tx_adapter event_timer_adapter event_crypto_adapter qos_framework @@ -52,7 +53,6 @@ Programmer's Guide packet_framework vhost_lib metrics_lib - port_hotplug_framework bpf_lib source_org dev_kit_build_system diff --git a/doc/guides/prog_guide/kernel_nic_interface.rst b/doc/guides/prog_guide/kernel_nic_interface.rst index 8fa13fa1..33ea980e 100644 --- a/doc/guides/prog_guide/kernel_nic_interface.rst +++ b/doc/guides/prog_guide/kernel_nic_interface.rst @@ -29,58 +29,222 @@ The components of an application using the DPDK Kernel NIC Interface are shown i The DPDK KNI Kernel Module -------------------------- -The KNI kernel loadable module provides support for two types of devices: +The KNI kernel loadable module ``rte_kni`` provides the kernel interface +for DPDK applications. -* A Miscellaneous device (/dev/kni) that: +When the ``rte_kni`` module is loaded, it will create a device ``/dev/kni`` +that is used by the DPDK KNI API functions to control and communicate with +the kernel module. - * Creates net devices (via ioctl calls). +The ``rte_kni`` kernel module contains several optional parameters which +can be specified when the module is loaded to control its behavior: - * Maintains a kernel thread context shared by all KNI instances - (simulating the RX side of the net driver). +.. code-block:: console - * For single kernel thread mode, maintains a kernel thread context shared by all KNI instances - (simulating the RX side of the net driver). + # modinfo rte_kni.ko + <snip> + parm: lo_mode: KNI loopback mode (default=lo_mode_none): + lo_mode_none Kernel loopback disabled + lo_mode_fifo Enable kernel loopback with fifo + lo_mode_fifo_skb Enable kernel loopback with fifo and skb buffer + (charp) + parm: kthread_mode: Kernel thread mode (default=single): + single Single kernel thread mode enabled. + multiple Multiple kernel thread mode enabled. + (charp) + parm: carrier: Default carrier state for KNI interface (default=off): + off Interfaces will be created with carrier state set to off. + on Interfaces will be created with carrier state set to on. + (charp) - * For multiple kernel thread mode, maintains a kernel thread context for each KNI instance - (simulating the RX side of the net driver). +Loading the ``rte_kni`` kernel module without any optional parameters is +the typical way a DPDK application gets packets into and out of the kernel +network stack. Without any parameters, only one kernel thread is created +for all KNI devices for packet receiving in kernel side, loopback mode is +disabled, and the default carrier state of KNI interfaces is set to *off*. -* Net device: +.. code-block:: console - * Net functionality provided by implementing several operations such as netdev_ops, - header_ops, ethtool_ops that are defined by struct net_device, - including support for DPDK mbufs and FIFOs. + # insmod kmod/rte_kni.ko - * The interface name is provided from userspace. +.. _kni_loopback_mode: - * The MAC address can be the real NIC MAC address or random. +Loopback Mode +~~~~~~~~~~~~~ + +For testing, the ``rte_kni`` kernel module can be loaded in loopback mode +by specifying the ``lo_mode`` parameter: + +.. code-block:: console + + # insmod kmod/rte_kni.ko lo_mode=lo_mode_fifo + +The ``lo_mode_fifo`` loopback option will loop back ring enqueue/dequeue +operations in kernel space. + +.. code-block:: console + + # insmod kmod/rte_kni.ko lo_mode=lo_mode_fifo_skb + +The ``lo_mode_fifo_skb`` loopback option will loop back ring enqueue/dequeue +operations and sk buffer copies in kernel space. + +If the ``lo_mode`` parameter is not specified, loopback mode is disabled. + +.. _kni_kernel_thread_mode: + +Kernel Thread Mode +~~~~~~~~~~~~~~~~~~ + +To provide flexibility of performance, the ``rte_kni`` KNI kernel module +can be loaded with the ``kthread_mode`` parameter. The ``rte_kni`` kernel +module supports two options: "single kernel thread" mode and "multiple +kernel thread" mode. + +Single kernel thread mode is enabled as follows: + +.. code-block:: console + + # insmod kmod/rte_kni.ko kthread_mode=single + +This mode will create only one kernel thread for all KNI interfaces to +receive data on the kernel side. By default, this kernel thread is not +bound to any particular core, but the user can set the core affinity for +this kernel thread by setting the ``core_id`` and ``force_bind`` parameters +in ``struct rte_kni_conf`` when the first KNI interface is created: + +For optimum performance, the kernel thread should be bound to a core in +on the same socket as the DPDK lcores used in the application. + +The KNI kernel module can also be configured to start a separate kernel +thread for each KNI interface created by the DPDK application. Multiple +kernel thread mode is enabled as follows: + +.. code-block:: console + + # insmod kmod/rte_kni.ko kthread_mode=multiple + +This mode will create a separate kernel thread for each KNI interface to +receive data on the kernel side. The core affinity of each ``kni_thread`` +kernel thread can be specified by setting the ``core_id`` and ``force_bind`` +parameters in ``struct rte_kni_conf`` when each KNI interface is created. + +Multiple kernel thread mode can provide scalable higher performance if +sufficient unused cores are available on the host system. + +If the ``kthread_mode`` parameter is not specified, the "single kernel +thread" mode is used. + +.. _kni_default_carrier_state: + +Default Carrier State +~~~~~~~~~~~~~~~~~~~~~ + +The default carrier state of KNI interfaces created by the ``rte_kni`` +kernel module is controlled via the ``carrier`` option when the module +is loaded. + +If ``carrier=off`` is specified, the kernel module will leave the carrier +state of the interface *down* when the interface is management enabled. +The DPDK application can set the carrier state of the KNI interface using the +``rte_kni_update_link()`` function. This is useful for DPDK applications +which require that the carrier state of the KNI interface reflect the +actual link state of the corresponding physical NIC port. + +If ``carrier=on`` is specified, the kernel module will automatically set +the carrier state of the interface to *up* when the interface is management +enabled. This is useful for DPDK applications which use the KNI interface as +a purely virtual interface that does not correspond to any physical hardware +and do not wish to explicitly set the carrier state of the interface with +``rte_kni_update_link()``. It is also useful for testing in loopback mode +where the NIC port may not be physically connected to anything. + +To set the default carrier state to *on*: + +.. code-block:: console + + # insmod kmod/rte_kni.ko carrier=on + +To set the default carrier state to *off*: + +.. code-block:: console + + # insmod kmod/rte_kni.ko carrier=off + +If the ``carrier`` parameter is not specified, the default carrier state +of KNI interfaces will be set to *off*. KNI Creation and Deletion ------------------------- -The KNI interfaces are created by a DPDK application dynamically. -The interface name and FIFO details are provided by the application through an ioctl call -using the rte_kni_device_info struct which contains: +Before any KNI interfaces can be created, the ``rte_kni`` kernel module must +be loaded into the kernel and configured withe ``rte_kni_init()`` function. + +The KNI interfaces are created by a DPDK application dynamically via the +``rte_kni_alloc()`` function. + +The ``struct rte_kni_conf`` structure contains fields which allow the +user to specify the interface name, set the MTU size, set an explicit or +random MAC address and control the affinity of the kernel Rx thread(s) +(both single and multi-threaded modes). + +The ``struct rte_kni_ops`` structure contains pointers to functions to +handle requests from the ``rte_kni`` kernel module. These functions +allow DPDK applications to perform actions when the KNI interfaces are +manipulated by control commands or functions external to the application. + +For example, the DPDK application may wish to enabled/disable a physical +NIC port when a user enabled/disables a KNI interface with ``ip link set +[up|down] dev <ifaceX>``. The DPDK application can register a callback for +``config_network_if`` which will be called when the interface management +state changes. + +There are currently four callbacks for which the user can register +application functions: -* The interface name. +``config_network_if``: -* Physical addresses of the corresponding memzones for the relevant FIFOs. + Called when the management state of the KNI interface changes. + For example, when the user runs ``ip link set [up|down] dev <ifaceX>``. -* Mbuf mempool details, both physical and virtual (to calculate the offset for mbuf pointers). +``change_mtu``: -* PCI information. + Called when the user changes the MTU size of the KNI + interface. For example, when the user runs ``ip link set mtu <size> + dev <ifaceX>``. -* Core affinity. +``config_mac_address``: -Refer to rte_kni_common.h in the DPDK source code for more details. + Called when the user changes the MAC address of the KNI interface. + For example, when the user runs ``ip link set address <MAC> + dev <ifaceX>``. If the user sets this callback function to NULL, + but sets the ``port_id`` field to a value other than -1, a default + callback handler in the rte_kni library ``kni_config_mac_address()`` + will be called which calls ``rte_eth_dev_default_mac_addr_set()`` + on the specified ``port_id``. -The physical addresses will be re-mapped into the kernel address space and stored in separate KNI contexts. +``config_promiscusity``: -The affinity of kernel RX thread (both single and multi-threaded modes) is controlled by force_bind and -core_id config parameters. + Called when the user changes the promiscusity state of the KNI + interface. For example, when the user runs ``ip link set promisc + [on|off] dev <ifaceX>``. If the user sets this callback function to + NULL, but sets the ``port_id`` field to a value other than -1, a default + callback handler in the rte_kni library ``kni_config_promiscusity()`` + will be called which calls ``rte_eth_promiscuous_<enable|disable>()`` + on the specified ``port_id``. -The KNI interfaces can be deleted by a DPDK application dynamically after being created. -Furthermore, all those KNI interfaces not deleted will be deleted on the release operation -of the miscellaneous device (when the DPDK application is closed). +In order to run these callbacks, the application must periodically call +the ``rte_kni_handle_request()`` function. Any user callback function +registered will be called directly from ``rte_kni_handle_request()`` so +care must be taken to prevent deadlock and to not block any DPDK fastpath +tasks. Typically DPDK applications which use these callbacks will need +to create a separate thread or secondary process to periodically call +``rte_kni_handle_request()``. + +The KNI interfaces can be deleted by a DPDK application with +``rte_kni_release()``. All KNI interfaces not explicitly deleted will be +deleted when the the ``/dev/kni`` device is closed, either explicitly with +``rte_kni_close()`` or when the DPDK application is closed. DPDK mbuf Flow -------------- @@ -118,7 +282,7 @@ The packet is received from the Linux net stack, by calling the kni_net_tx() cal The mbuf is dequeued (without waiting due the cache) and filled with data from sk_buff. The sk_buff is then freed and the mbuf sent in the tx_q FIFO. -The DPDK TX thread dequeues the mbuf and sends it to the PMD (via rte_eth_tx_burst()). +The DPDK TX thread dequeues the mbuf and sends it to the PMD via ``rte_eth_tx_burst()``. It then puts the mbuf back in the cache. Ethtool @@ -128,16 +292,3 @@ Ethtool is a Linux-specific tool with corresponding support in the kernel where each net device must register its own callbacks for the supported operations. The current implementation uses the igb/ixgbe modified Linux drivers for ethtool support. Ethtool is not supported in i40e and VMs (VF or EM devices). - -Link state and MTU change -------------------------- - -Link state and MTU change are network interface specific operations usually done via ifconfig. -The request is initiated from the kernel side (in the context of the ifconfig process) -and handled by the user space DPDK application. -The application polls the request, calls the application handler and returns the response back into the kernel space. - -The application handlers can be registered upon interface creation or explicitly registered/unregistered in runtime. -This provides flexibility in multiprocess scenarios -(where the KNI is created in the primary process but the callbacks are handled in the secondary one). -The constraint is that a single process can register and handle the requests. diff --git a/doc/guides/prog_guide/packet_framework.rst b/doc/guides/prog_guide/packet_framework.rst index f0b48566..48d25750 100644 --- a/doc/guides/prog_guide/packet_framework.rst +++ b/doc/guides/prog_guide/packet_framework.rst @@ -98,6 +98,10 @@ Port Types | | | character device. | | | | | +---+------------------+---------------------------------------------------------------------------------------+ + | 9 | Sym_crypto | Output port used to extract DPDK Cryptodev operations from a fixed offset of the | + | | | packet and then enqueue to the Cryptodev PMD. Input port used to dequeue the | + | | | Cryptodev operations from the Cryptodev PMD and then retrieve the packets from them. | + +---+------------------+---------------------------------------------------------------------------------------+ Port Interface ~~~~~~~~~~~~~~ @@ -1078,6 +1082,11 @@ with each table entry having its own set of enabled user actions and its own cop | | | checksum. | | | | | +---+-----------------------------------+---------------------------------------------------------------------+ + | 7 | Sym Crypto | Generate Cryptodev session based on the user-specified algorithm | + | | | and key(s), and assemble the cryptodev operation based on the | + | | | predefined offsets. | + | | | | + +---+-----------------------------------+---------------------------------------------------------------------+ Multicore Scaling ----------------- @@ -1133,7 +1142,7 @@ Typical devices with acceleration capabilities are: * Inline accelerators: NICs, switches, FPGAs, etc; -* Look-aside accelerators: chipsets, FPGAs, etc. +* Look-aside accelerators: chipsets, FPGAs, Intel QuickAssist, etc. Usually, to support a specific functional block, specific implementation of Packet Framework tables and/or ports and/or actions has to be provided for each accelerator, with all the implementations sharing the same API: pure SW implementation (no acceleration), implementation using accelerator A, implementation using accelerator B, etc. diff --git a/doc/guides/prog_guide/port_hotplug_framework.rst b/doc/guides/prog_guide/port_hotplug_framework.rst deleted file mode 100644 index fb0efc18..00000000 --- a/doc/guides/prog_guide/port_hotplug_framework.rst +++ /dev/null @@ -1,106 +0,0 @@ -.. BSD LICENSE - Copyright(c) 2015 IGEL Co.,Ltd. All rights reserved. - All rights reserved. - - Redistribution and use in source and binary forms, with or without - modification, are permitted provided that the following conditions - are met: - - * Redistributions of source code must retain the above copyright - notice, this list of conditions and the following disclaimer. - * Redistributions in binary form must reproduce the above copyright - notice, this list of conditions and the following disclaimer in - the documentation and/or other materials provided with the - distribution. - * Neither the name of IGEL Co.,Ltd. nor the names of its - contributors may be used to endorse or promote products derived - from this software without specific prior written permission. - - THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS - "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT - LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR - A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT - OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, - SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT - LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, - DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY - THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT - (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE - OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. - -Port Hotplug Framework -====================== - -The Port Hotplug Framework provides DPDK applications with the ability to -attach and detach ports at runtime. Because the framework depends on PMD -implementation, the ports that PMDs cannot handle are out of scope of this -framework. Furthermore, after detaching a port from a DPDK application, the -framework doesn't provide a way for removing the devices from the system. -For the ports backed by a physical NIC, the kernel will need to support PCI -Hotplug feature. - -Overview --------- - -The basic requirements of the Port Hotplug Framework are: - -* DPDK applications that use the Port Hotplug Framework must manage their - own ports. - - The Port Hotplug Framework is implemented to allow DPDK applications to - manage ports. For example, when DPDK applications call the port attach - function, the attached port number is returned. DPDK applications can - also detach the port by port number. - -* Kernel support is needed for attaching or detaching physical device - ports. - - To attach new physical device ports, the device will be recognized by - userspace driver I/O framework in kernel at first. Then DPDK - applications can call the Port Hotplug functions to attach the ports. - For detaching, steps are vice versa. - -* Before detaching, they must be stopped and closed. - - DPDK applications must call "rte_eth_dev_stop()" and - "rte_eth_dev_close()" APIs before detaching ports. These functions will - start finalization sequence of the PMDs. - -* The framework doesn't affect legacy DPDK applications behavior. - - If the Port Hotplug functions aren't called, all legacy DPDK apps can - still work without modifications. - -Port Hotplug API overview -------------------------- - -* Attaching a port - - "rte_eth_dev_attach()" API attaches a port to DPDK application, and - returns the attached port number. Before calling the API, the device - should be recognized by an userspace driver I/O framework. The API - receives a pci address like "0000:01:00.0" or a virtual device name - like "net_pcap0,iface=eth0". In the case of virtual device name, the - format is the same as the general "--vdev" option of DPDK. - -* Detaching a port - - "rte_eth_dev_detach()" API detaches a port from DPDK application, and - returns a pci address of the detached device or a virtual device name - of the device. - -Reference ---------- - - "testpmd" supports the Port Hotplug Framework. - -Limitations ------------ - -* The Port Hotplug APIs are not thread safe. - -* The framework can only be enabled with Linux. BSD is not supported. - -* Not all PMDs support detaching feature. - The underlying bus must support hot-unplug. If not supported, - the function ``rte_eth_dev_detach()`` will return negative ENOTSUP. diff --git a/doc/guides/prog_guide/power_man.rst b/doc/guides/prog_guide/power_man.rst index eba1cc6b..68b7e8b6 100644 --- a/doc/guides/prog_guide/power_man.rst +++ b/doc/guides/prog_guide/power_man.rst @@ -106,6 +106,92 @@ User Cases The power management mechanism is used to save power when performing L3 forwarding. + +Empty Poll API +-------------- + +Abstract +~~~~~~~~ + +For packet processing workloads such as DPDK polling is continuous. +This means CPU cores always show 100% busy independent of how much work +those cores are doing. It is critical to accurately determine how busy +a core is hugely important for the following reasons: + + * No indication of overload conditions + * User does not know how much real load is on a system, resulting + in wasted energy as no power management is utilized + +Compared to the original l3fwd-power design, instead of going to sleep +after detecting an empty poll, the new mechanism just lowers the core frequency. +As a result, the application does not stop polling the device, which leads +to improved handling of bursts of traffic. + +When the system become busy, the empty poll mechanism can also increase the core +frequency (including turbo) to do best effort for intensive traffic. This gives +us more flexible and balanced traffic awareness over the standard l3fwd-power +application. + + +Proposed Solution +~~~~~~~~~~~~~~~~~ +The proposed solution focuses on how many times empty polls are executed. +The less the number of empty polls, means current core is busy with processing +workload, therefore, the higher frequency is needed. The high empty poll number +indicates the current core not doing any real work therefore, we can lower the +frequency to safe power. + +In the current implementation, each core has 1 empty-poll counter which assume +1 core is dedicated to 1 queue. This will need to be expanded in the future to +support multiple queues per core. + +Power state definition: +^^^^^^^^^^^^^^^^^^^^^^^ + +* LOW: Not currently used, reserved for future use. + +* MED: the frequency is used to process modest traffic workload. + +* HIGH: the frequency is used to process busy traffic workload. + +There are two phases to establish the power management system: +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +* Training phase. This phase is used to measure the optimal frequency + change thresholds for a given system. The thresholds will differ from + system to system due to differences in processor micro-architecture, + cache and device configurations. + In this phase, the user must ensure that no traffic can enter the + system so that counts can be measured for empty polls at low, medium + and high frequencies. Each frequency is measured for two seconds. + Once the training phase is complete, the threshold numbers are + displayed, and normal mode resumes, and traffic can be allowed into + the system. These threshold number can be used on the command line + when starting the application in normal mode to avoid re-training + every time. + +* Normal phase. Every 10ms the run-time counters are compared + to the supplied threshold values, and the decision will be made + whether to move to a different power state (by adjusting the + frequency). + +API Overview for Empty Poll Power Management +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +* **State Init**: initialize the power management system. + +* **State Free**: free the resource hold by power management system. + +* **Update Empty Poll Counter**: update the empty poll counter. + +* **Update Valid Poll Counter**: update the valid poll counter. + +* **Set the Fequence Index**: update the power state/frequency mapping. + +* **Detect empty poll state change**: empty poll state change detection algorithm then take action. + +User Cases +---------- +The mechanism can applied to any device which is based on polling. e.g. NIC, FPGA. + References ---------- diff --git a/doc/guides/prog_guide/profile_app.rst b/doc/guides/prog_guide/profile_app.rst index 1106216a..02f05614 100644 --- a/doc/guides/prog_guide/profile_app.rst +++ b/doc/guides/prog_guide/profile_app.rst @@ -33,38 +33,12 @@ Refer to the for details about application profiling. -Empty cycles tracing +Profiling with VTune ~~~~~~~~~~~~~~~~~~~~ -Iterations that yielded no RX packets (empty cycles, wasted iterations) can -be analyzed using VTune Amplifier. This profiling employs the -`Instrumentation and Tracing Technology (ITT) API -<https://software.intel.com/en-us/node/544195>`_ -feature of VTune Amplifier and requires only reconfiguring the DPDK library, -no changes in a DPDK application are needed. - -To trace wasted iterations on RX queues, first reconfigure DPDK with -``CONFIG_RTE_ETHDEV_RXTX_CALLBACKS`` and -``CONFIG_RTE_ETHDEV_PROFILE_ITT_WASTED_RX_ITERATIONS`` enabled. - -Then rebuild DPDK, specifying paths to the ITT header and library, which can -be found in any VTune Amplifier distribution in the *include* and *lib* -directories respectively: - -.. code-block:: console - - make EXTRA_CFLAGS=-I<path to ittnotify.h> \ - EXTRA_LDLIBS="-L<path to libittnotify.a> -littnotify" - -Finally, to see wasted iterations in your performance analysis results, -select the *"Analyze user tasks, events, and counters"* checkbox in the -*"Analysis Type"* tab when configuring analysis via VTune Amplifier GUI. -Alternatively, when running VTune Amplifier via command line, specify -``-knob enable-user-tasks=true`` option. - -Collected regions of wasted iterations will be marked on VTune Amplifier's -timeline as ITT tasks. These ITT tasks have predefined names, containing -Ethernet device and RX queue identifiers. +To allow VTune attaching to the DPDK application, reconfigure and recompile +the DPDK with ``CONFIG_RTE_ETHDEV_RXTX_CALLBACKS`` and +``CONFIG_RTE_ETHDEV_PROFILE_WITH_VTUNE`` enabled. Profiling on ARM64 diff --git a/doc/guides/prog_guide/rte_flow.rst b/doc/guides/prog_guide/rte_flow.rst index b305a72a..c1863750 100644 --- a/doc/guides/prog_guide/rte_flow.rst +++ b/doc/guides/prog_guide/rte_flow.rst @@ -1191,6 +1191,27 @@ Normally preceded by any of: - `Item: ICMP6_ND_NS`_ - `Item: ICMP6_ND_OPT`_ +Item: ``META`` +^^^^^^^^^^^^^^ + +Matches an application specific 32 bit metadata item. + +- Default ``mask`` matches the specified metadata value. + +.. _table_rte_flow_item_meta: + +.. table:: META + + +----------+----------+---------------------------------------+ + | Field | Subfield | Value | + +==========+==========+=======================================+ + | ``spec`` | ``data`` | 32 bit metadata value | + +----------+--------------------------------------------------+ + | ``last`` | ``data`` | upper range value | + +----------+----------+---------------------------------------+ + | ``mask`` | ``data`` | bit-mask applies to "spec" and "last" | + +----------+----------+---------------------------------------+ + Actions ~~~~~~~ @@ -2076,6 +2097,250 @@ RTE_FLOW_ERROR_TYPE_ACTION error should be returned. This action modifies the payload of matched flows. +Action: ``RAW_ENCAP`` +^^^^^^^^^^^^^^^^^^^^^ + +Adds outer header whose template is provided in its data buffer, +as defined in the ``rte_flow_action_raw_encap`` definition. + +This action modifies the payload of matched flows. The data supplied must +be a valid header, either holding layer 2 data in case of adding layer 2 after +decap layer 3 tunnel (for example MPLSoGRE) or complete tunnel definition +starting from layer 2 and moving to the tunnel item itself. When applied to +the original packet the resulting packet must be a valid packet. + +.. _table_rte_flow_action_raw_encap: + +.. table:: RAW_ENCAP + + +----------------+----------------------------------------+ + | Field | Value | + +================+========================================+ + | ``data`` | Encapsulation data | + +----------------+----------------------------------------+ + | ``preserve`` | Bit-mask of data to preserve on output | + +----------------+----------------------------------------+ + | ``size`` | Size of data and preserve | + +----------------+----------------------------------------+ + +Action: ``RAW_DECAP`` +^^^^^^^^^^^^^^^^^^^^^^^ + +Remove outer header whose template is provided in its data buffer, +as defined in the ``rte_flow_action_raw_decap`` + +This action modifies the payload of matched flows. The data supplied must +be a valid header, either holding layer 2 data in case of removing layer 2 +before eincapsulation of layer 3 tunnel (for example MPLSoGRE) or complete +tunnel definition starting from layer 2 and moving to the tunnel item itself. +When applied to the original packet the resulting packet must be a +valid packet. + +.. _table_rte_flow_action_raw_decap: + +.. table:: RAW_DECAP + + +----------------+----------------------------------------+ + | Field | Value | + +================+========================================+ + | ``data`` | Decapsulation data | + +----------------+----------------------------------------+ + | ``size`` | Size of data | + +----------------+----------------------------------------+ + +Action: ``SET_IPV4_SRC`` +^^^^^^^^^^^^^^^^^^^^^^^^ + +Set a new IPv4 source address in the outermost IPv4 header. + +It must be used with a valid RTE_FLOW_ITEM_TYPE_IPV4 flow pattern item. +Otherwise, RTE_FLOW_ERROR_TYPE_ACTION error will be returned. + +.. _table_rte_flow_action_set_ipv4_src: + +.. table:: SET_IPV4_SRC + + +-----------------------------------------+ + | Field | Value | + +===============+=========================+ + | ``ipv4_addr`` | new IPv4 source address | + +---------------+-------------------------+ + +Action: ``SET_IPV4_DST`` +^^^^^^^^^^^^^^^^^^^^^^^^ + +Set a new IPv4 destination address in the outermost IPv4 header. + +It must be used with a valid RTE_FLOW_ITEM_TYPE_IPV4 flow pattern item. +Otherwise, RTE_FLOW_ERROR_TYPE_ACTION error will be returned. + +.. _table_rte_flow_action_set_ipv4_dst: + +.. table:: SET_IPV4_DST + + +---------------+------------------------------+ + | Field | Value | + +===============+==============================+ + | ``ipv4_addr`` | new IPv4 destination address | + +---------------+------------------------------+ + +Action: ``SET_IPV6_SRC`` +^^^^^^^^^^^^^^^^^^^^^^^^ + +Set a new IPv6 source address in the outermost IPv6 header. + +It must be used with a valid RTE_FLOW_ITEM_TYPE_IPV6 flow pattern item. +Otherwise, RTE_FLOW_ERROR_TYPE_ACTION error will be returned. + +.. _table_rte_flow_action_set_ipv6_src: + +.. table:: SET_IPV6_SRC + + +---------------+-------------------------+ + | Field | Value | + +===============+=========================+ + | ``ipv6_addr`` | new IPv6 source address | + +---------------+-------------------------+ + +Action: ``SET_IPV6_DST`` +^^^^^^^^^^^^^^^^^^^^^^^^ + +Set a new IPv6 destination address in the outermost IPv6 header. + +It must be used with a valid RTE_FLOW_ITEM_TYPE_IPV6 flow pattern item. +Otherwise, RTE_FLOW_ERROR_TYPE_ACTION error will be returned. + +.. _table_rte_flow_action_set_ipv6_dst: + +.. table:: SET_IPV6_DST + + +---------------+------------------------------+ + | Field | Value | + +===============+==============================+ + | ``ipv6_addr`` | new IPv6 destination address | + +---------------+------------------------------+ + +Action: ``SET_TP_SRC`` +^^^^^^^^^^^^^^^^^^^^^^^^^ + +Set a new source port number in the outermost TCP/UDP header. + +It must be used with a valid RTE_FLOW_ITEM_TYPE_TCP or RTE_FLOW_ITEM_TYPE_UDP +flow pattern item. Otherwise, RTE_FLOW_ERROR_TYPE_ACTION error will be returned. + +.. _table_rte_flow_action_set_tp_src: + +.. table:: SET_TP_SRC + + +----------+-------------------------+ + | Field | Value | + +==========+=========================+ + | ``port`` | new TCP/UDP source port | + +---------------+--------------------+ + +Action: ``SET_TP_DST`` +^^^^^^^^^^^^^^^^^^^^^^^^^ + +Set a new destination port number in the outermost TCP/UDP header. + +It must be used with a valid RTE_FLOW_ITEM_TYPE_TCP or RTE_FLOW_ITEM_TYPE_UDP +flow pattern item. Otherwise, RTE_FLOW_ERROR_TYPE_ACTION error will be returned. + +.. _table_rte_flow_action_set_tp_dst: + +.. table:: SET_TP_DST + + +----------+------------------------------+ + | Field | Value | + +==========+==============================+ + | ``port`` | new TCP/UDP destination port | + +---------------+-------------------------+ + +Action: ``MAC_SWAP`` +^^^^^^^^^^^^^^^^^^^^^^^^^ + +Swap the source and destination MAC addresses in the outermost Ethernet +header. + +It must be used with a valid RTE_FLOW_ITEM_TYPE_ETH flow pattern item. +Otherwise, RTE_FLOW_ERROR_TYPE_ACTION error will be returned. + +.. _table_rte_flow_action_mac_swap: + +.. table:: MAC_SWAP + + +---------------+ + | Field | + +===============+ + | no properties | + +---------------+ + +Action: ``DEC_TTL`` +^^^^^^^^^^^^^^^^^^^ + +Decrease TTL value. + +If there is no valid RTE_FLOW_ITEM_TYPE_IPV4 or RTE_FLOW_ITEM_TYPE_IPV6 +in pattern, Some PMDs will reject rule because behaviour will be undefined. + +.. _table_rte_flow_action_dec_ttl: + +.. table:: DEC_TTL + + +---------------+ + | Field | + +===============+ + | no properties | + +---------------+ + +Action: ``SET_TTL`` +^^^^^^^^^^^^^^^^^^^ + +Assigns a new TTL value. + +If there is no valid RTE_FLOW_ITEM_TYPE_IPV4 or RTE_FLOW_ITEM_TYPE_IPV6 +in pattern, Some PMDs will reject rule because behaviour will be undefined. + +.. _table_rte_flow_action_set_ttl: + +.. table:: SET_TTL + + +---------------+--------------------+ + | Field | Value | + +===============+====================+ + | ``ttl_value`` | new TTL value | + +---------------+--------------------+ + +Action: ``SET_MAC_SRC`` +^^^^^^^^^^^^^^^^^^^^^^^ + +Set source MAC address + +.. _table_rte_flow_action_set_mac_src: + +.. table:: SET_MAC_SRC + + +--------------+---------------+ + | Field | Value | + +==============+===============+ + | ``mac_addr`` | MAC address | + +--------------+---------------+ + +Action: ``SET_MAC_DST`` +^^^^^^^^^^^^^^^^^^^^^^^ + +Set source MAC address + +.. _table_rte_flow_action_set_mac_dst: + +.. table:: SET_MAC_DST + + +--------------+---------------+ + | Field | Value | + +==============+===============+ + | ``mac_addr`` | MAC address | + +--------------+---------------+ + Negative types ~~~~~~~~~~~~~~ @@ -2419,6 +2684,26 @@ This function initializes ``error`` (if non-NULL) with the provided parameters and sets ``rte_errno`` to ``code``. A negative error ``code`` is then returned. +Object conversion +~~~~~~~~~~~~~~~~~ + +.. code-block:: c + + int + rte_flow_conv(enum rte_flow_conv_op op, + void *dst, + size_t size, + const void *src, + struct rte_flow_error *error); + +Convert ``src`` to ``dst`` according to operation ``op``. Possible +operations include: + +- Attributes, pattern item or action duplication. +- Duplication of an entire pattern or list of actions. +- Duplication of a complete flow rule description. +- Pattern item or action name retrieval. + Caveats ------- diff --git a/doc/guides/prog_guide/rte_security.rst b/doc/guides/prog_guide/rte_security.rst index 0812abe7..cb70caa7 100644 --- a/doc/guides/prog_guide/rte_security.rst +++ b/doc/guides/prog_guide/rte_security.rst @@ -10,8 +10,8 @@ The security library provides a framework for management and provisioning of security protocol operations offloaded to hardware based devices. The library defines generic APIs to create and free security sessions which can support full protocol offload as well as inline crypto operation with -NIC or crypto devices. The framework currently only supports the IPSec protocol -and associated operations, other protocols will be added in future. +NIC or crypto devices. The framework currently only supports the IPsec and PDCP +protocol and associated operations, other protocols will be added in future. Design Principles ----------------- @@ -253,6 +253,49 @@ for any protocol header addition. +--------|--------+ V +PDCP Flow Diagram +~~~~~~~~~~~~~~~~~ + +Based on 3GPP TS 36.323 Evolved Universal Terrestrial Radio Access (E-UTRA); +Packet Data Convergence Protocol (PDCP) specification + +.. code-block:: c + + Transmitting PDCP Entity Receiving PDCP Entity + | ^ + | +-----------|-----------+ + V | In order delivery and | + +---------|----------+ | Duplicate detection | + | Sequence Numbering | | (Data Plane only) | + +---------|----------+ +-----------|-----------+ + | | + +---------|----------+ +-----------|----------+ + | Header Compression*| | Header Decompression*| + | (Data-Plane only) | | (Data Plane only) | + +---------|----------+ +-----------|----------+ + | | + +---------|-----------+ +-----------|----------+ + | Integrity Protection| |Integrity Verification| + | (Control Plane only)| | (Control Plane only) | + +---------|-----------+ +-----------|----------+ + +---------|-----------+ +----------|----------+ + | Ciphering | | Deciphering | + +---------|-----------+ +----------|----------+ + +---------|-----------+ +----------|----------+ + | Add PDCP header | | Remove PDCP Header | + +---------|-----------+ +----------|----------+ + | | + +----------------->>----------------+ + + +.. note:: + + * Header Compression and decompression are not supported currently. + +Just like IPsec, in case of PDCP also header addition/deletion, cipher/ +de-cipher, integrity protection/verification is done based on the action +type chosen. + Device Features and Capabilities --------------------------------- @@ -271,7 +314,7 @@ structure in the *DPDK API Reference*. Each driver (crypto or ethernet) defines its own private array of capabilities for the operations it supports. Below is an example of the capabilities for a -PMD which supports the IPSec protocol. +PMD which supports the IPsec and PDCP protocol. .. code-block:: c @@ -298,6 +341,24 @@ PMD which supports the IPSec protocol. }, .crypto_capabilities = pmd_capabilities }, + { /* PDCP Lookaside Protocol offload Data Plane */ + .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, + .protocol = RTE_SECURITY_PROTOCOL_PDCP, + .pdcp = { + .domain = RTE_SECURITY_PDCP_MODE_DATA, + .capa_flags = 0 + }, + .crypto_capabilities = pmd_capabilities + }, + { /* PDCP Lookaside Protocol offload Control */ + .action = RTE_SECURITY_ACTION_TYPE_LOOKASIDE_PROTOCOL, + .protocol = RTE_SECURITY_PROTOCOL_PDCP, + .pdcp = { + .domain = RTE_SECURITY_PDCP_MODE_CONTROL, + .capa_flags = 0 + }, + .crypto_capabilities = pmd_capabilities + }, { .action = RTE_SECURITY_ACTION_TYPE_NONE } @@ -429,6 +490,7 @@ Security Session configuration structure is defined as ``rte_security_session_co union { struct rte_security_ipsec_xform ipsec; struct rte_security_macsec_xform macsec; + struct rte_security_pdcp_xform pdcp; }; /**< Configuration parameters for security session */ struct rte_crypto_sym_xform *crypto_xform; @@ -463,15 +525,17 @@ The ``rte_security_session_protocol`` is defined as .. code-block:: c enum rte_security_session_protocol { - RTE_SECURITY_PROTOCOL_IPSEC, + RTE_SECURITY_PROTOCOL_IPSEC = 1, /**< IPsec Protocol */ RTE_SECURITY_PROTOCOL_MACSEC, /**< MACSec Protocol */ + RTE_SECURITY_PROTOCOL_PDCP, + /**< PDCP Protocol */ }; -Currently the library defines configuration parameters for IPSec only. For other -protocols like MACSec, structures and enums are defined as place holders which -will be updated in the future. +Currently the library defines configuration parameters for IPsec and PDCP only. +For other protocols like MACSec, structures and enums are defined as place holders +which will be updated in the future. IPsec related configuration parameters are defined in ``rte_security_ipsec_xform`` @@ -494,6 +558,35 @@ IPsec related configuration parameters are defined in ``rte_security_ipsec_xform /**< Tunnel parameters, NULL for transport mode */ }; +PDCP related configuration parameters are defined in ``rte_security_pdcp_xform`` + +.. code-block:: c + + struct rte_security_pdcp_xform { + int8_t bearer; /**< PDCP bearer ID */ + /** Enable in order delivery, this field shall be set only if + * driver/HW is capable. See RTE_SECURITY_PDCP_ORDERING_CAP. + */ + uint8_t en_ordering; + /** Notify driver/HW to detect and remove duplicate packets. + * This field should be set only when driver/hw is capable. + * See RTE_SECURITY_PDCP_DUP_DETECT_CAP. + */ + uint8_t remove_duplicates; + /** PDCP mode of operation: Control or data */ + enum rte_security_pdcp_domain domain; + /** PDCP Frame Direction 0:UL 1:DL */ + enum rte_security_pdcp_direction pkt_dir; + /** Sequence number size, 5/7/12/15/18 */ + enum rte_security_pdcp_sn_size sn_size; + /** Starting Hyper Frame Number to be used together with the SN + * from the PDCP frames + */ + uint32_t hfn; + /** HFN Threshold for key renegotiation */ + uint32_t hfn_threshold; + }; + Security API ~~~~~~~~~~~~ diff --git a/doc/guides/prog_guide/vhost_lib.rst b/doc/guides/prog_guide/vhost_lib.rst index 77af4d77..c77df338 100644 --- a/doc/guides/prog_guide/vhost_lib.rst +++ b/doc/guides/prog_guide/vhost_lib.rst @@ -106,6 +106,14 @@ The following is an overview of some key Vhost API functions: Enabling this flag with these Qemu version results in Qemu being blocked when multiple queue pairs are declared. + - ``RTE_VHOST_USER_POSTCOPY_SUPPORT`` + + Postcopy live-migration support will be enabled when this flag is set. + It is disabled by default. + + Enabling this flag should only be done when the calling application does + not pre-fault the guest shared memory, otherwise migration would fail. + * ``rte_vhost_driver_set_features(path, features)`` This function sets the feature bits the vhost-user driver supports. The diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index e2dbee31..34b28234 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -11,21 +11,6 @@ API and ABI deprecation notices are to be posted here. Deprecation Notices ------------------- -* eal: certain structures will change in EAL on account of upcoming external - memory support. Aside from internal changes leading to an ABI break, the - following externally visible changes will also be implemented: - - - ``rte_memseg_list`` will change to include a boolean flag indicating - whether a particular memseg list is externally allocated. This will have - implications for any users of memseg-walk-related functions, as they will - now have to skip externally allocated segments in most cases if the intent - is to only iterate over internal DPDK memory. - - ``socket_id`` parameter across the entire DPDK will gain additional meaning, - as some socket ID's will now be representing externally allocated memory. No - changes will be required for existing code as backwards compatibility will - be kept, and those who do not use this feature will not see these extra - socket ID's. - * eal: both declaring and identifying devices will be streamlined in v18.11. New functions will appear to query a specific port from buses, classes of device and device drivers. Device declaration will be made coherent with the @@ -56,12 +41,6 @@ Deprecation Notices experimental API ``rte_pktmbuf_attach_extbuf()`` is used. Removal of the macro is to fix this semantic inconsistency. -* ethdev: In v18.11 ``DEV_RX_OFFLOAD_CRC_STRIP`` offload flag will be removed, default - behavior without any flag will be changed to CRC strip. - To keep CRC ``DEV_RX_OFFLOAD_KEEP_CRC`` flag is required. - ``KEEP_CRC``: Keep CRC in packet - No flag: Strip CRC from packet - * ethdev: the legacy filter API, including ``rte_eth_dev_filter_supported()``, ``rte_eth_dev_filter_ctrl()`` as well as filter types MACVLAN, ETHERTYPE, FLEXIBLE, SYN, NTUPLE, TUNNEL, FDIR, @@ -70,28 +49,9 @@ Deprecation Notices Target release for removal of the legacy API will be defined once most PMDs have switched to rte_flow. -* ethdev: In v18.11 ``rte_eth_dev_attach()`` and ``rte_eth_dev_detach()`` - will be removed. - Hotplug functions ``rte_eal_hotplug_add()`` and ``rte_eal_hotplug_remove()`` - should be used instread. - Function ``rte_eth_dev_get_port_by_name()`` may be used to find - identifier of the added port. - -* eal: In v18.11 ``rte_eal_dev_attach()`` and ``rte_eal_dev_detach()`` - will be removed. - Hotplug functions ``rte_eal_hotplug_add()`` and ``rte_eal_hotplug_remove()`` - should be used directly. - * pdump: As we changed to use generic IPC, some changes in APIs and structure are expected in subsequent release. - ``rte_pdump_set_socket_dir`` will be removed; - The parameter, ``path``, of ``rte_pdump_init`` will be removed; - The enum ``rte_pdump_socktype`` will be removed. - -* ethdev: flow API function ``rte_flow_copy()`` will be deprecated in v18.11 - in favor of ``rte_flow_conv()`` (which will appear in that version) and - subsequently removed for v19.02. - - This is due to a lack of flexibility and reliance on a type unusable with - C++ programs (struct rte_flow_desc). diff --git a/doc/guides/rel_notes/index.rst b/doc/guides/rel_notes/index.rst index d125342c..1243e985 100644 --- a/doc/guides/rel_notes/index.rst +++ b/doc/guides/rel_notes/index.rst @@ -8,7 +8,7 @@ Release Notes :maxdepth: 1 :numbered: - rel_description + release_18_11 release_18_08 release_18_05 release_18_02 diff --git a/doc/guides/rel_notes/rel_description.rst b/doc/guides/rel_notes/rel_description.rst deleted file mode 100644 index 8f285566..00000000 --- a/doc/guides/rel_notes/rel_description.rst +++ /dev/null @@ -1,12 +0,0 @@ -.. SPDX-License-Identifier: BSD-3-Clause - Copyright(c) 2010-2015 Intel Corporation. - -Description of Release -====================== - -This document contains the release notes for Data Plane Development Kit (DPDK) -release version |release| and previous releases. - -It lists new features, fixed bugs, API and ABI changes and known issues. - -For instructions on compiling and running the release, see the :ref:`DPDK Getting Started Guide <linux_gsg>`. diff --git a/doc/guides/rel_notes/release_18_08.rst b/doc/guides/rel_notes/release_18_08.rst index 321fa845..8a09dee9 100644 --- a/doc/guides/rel_notes/release_18_08.rst +++ b/doc/guides/rel_notes/release_18_08.rst @@ -252,7 +252,7 @@ The libraries prepended with a plus sign were incremented in this version. librte_distributor.so.1 + librte_eal.so.8 + librte_ethdev.so.10 - librte_eventdev.so.4 + + librte_eventdev.so.5 librte_flow_classify.so.1 librte_gro.so.1 librte_gso.so.1 diff --git a/doc/guides/rel_notes/release_18_11.rst b/doc/guides/rel_notes/release_18_11.rst new file mode 100644 index 00000000..376128f6 --- /dev/null +++ b/doc/guides/rel_notes/release_18_11.rst @@ -0,0 +1,529 @@ +.. SPDX-License-Identifier: BSD-3-Clause + Copyright 2018 The DPDK contributors + +DPDK Release 18.11 +================== + +.. **Read this first.** + + The text in the sections below explains how to update the release notes. + + Use proper spelling, capitalization and punctuation in all sections. + + Variable and config names should be quoted as fixed width text: + ``LIKE_THIS``. + + Build the docs and view the output file to ensure the changes are correct:: + + make doc-guides-html + + xdg-open build/doc/html/guides/rel_notes/release_18_11.html + + +New Features +------------ + +.. This section should contain new features added in this release. + Sample format: + + * **Add a title in the past tense with a full stop.** + + Add a short 1-2 sentence description in the past tense. + The description should be enough to allow someone scanning + the release notes to understand the new feature. + + If the feature adds a lot of sub-features you can use a bullet list + like this: + + * Added feature foo to do something. + * Enhanced feature bar to do something else. + + Refer to the previous release notes for examples. + + Suggested order in release notes items: + * Core libs (EAL, mempool, ring, mbuf, buses) + * Device abstraction libs and PMDs + - ethdev (lib, PMDs) + - cryptodev (lib, PMDs) + - eventdev (lib, PMDs) + - etc + * Other libs + * Apps, Examples, Tools (if significative) + + This section is a comment. Do not overwrite or remove it. + Also, make sure to start the actual text at the margin. + ========================================================= + +* **Added support for using externally allocated memory in DPDK.** + + DPDK has gained support for creating new ``rte_malloc`` heaps referencing + memory that was created outside of DPDK's own page allocator, and using that + memory natively with any other DPDK library or data structure. + +* **Added check for ensuring allocated memory addressable by devices.** + + Some devices can have addressing limitations so a new function, + ``rte_eal_check_dma_mask``, has been added for checking allocated memory is + not out of the device range. Because now memory can be dynamically allocated + after initialization, a dma mask is kept and any new allocated memory will be + checked out against that dma mask and rejected if out of range. If more than + one device has addressing limitations, the dma mask is the more restricted one. + +* **Added hot-unplug handle mechanism.** + + ``rte_dev_hotplug_handle_enable`` and ``rte_dev_hotplug_handle_disable`` are + for enabling or disabling hotplug handle mechanism. + +* **Support device multi-process hotplug.** + + Hotplug and hot-unplug for devices will now be supported in multiprocessing + scenario. Any ethdev devices created in the primary process will be regarded + as shared and will be available for all DPDK processes. Synchronization + between processes will be done using DPDK IPC. + +* **Added new Flow API actions to rewrite fields in packet headers.** + + Added new Flow API actions to: + + * Modify source and destination IP addresses in the outermost IPv4/IPv6 + headers. + * Modify source and destination port numbers in the outermost TCP/UDP + headers. + +* **Added new Flow API action to swap MAC addresses in Ethernet header.** + + Added new Flow API action to swap the source and destination MAC + addresses in the outermost Ethernet header. + +* **Add support to offload more flow match and actions for CXGBE PMD** + + Flow API support has been enhanced for CXGBE Poll Mode Driver to offload: + + * Match items: destination MAC address. + * Action items: push/pop/rewrite vlan header, + rewrite IP addresses in outermost IPv4/IPv6 header, + rewrite port numbers in outermost TCP/UDP header, + swap MAC addresses in outermost Ethernet header. + +* **Added a devarg to use the latest supported vector path in i40e.** + A new devarg ``use-latest-supported-vec`` was introduced to allow users to + choose the latest vector path that the platform supported. For example, users + can use AVX2 vector path on BDW/HSW to get better performance. + +* **Added support for SR-IOV in netvsc PMD.** + + The ``netvsc`` poll mode driver now supports the Accelerated Networking + SR-IOV option in Hyper-V and Azure. This is an alternative to the previous + vdev_netvsc, tap, and failsafe drivers combination. + +* **Added a new net driver for Marvell Armada 3k device.** + + Added the new ``mvneta`` net driver for Marvell Armada 3k device. See the + :doc:`../nics/mvneta` NIC guide for more details on this new driver. + +* **Added NXP ENETC PMD.** + + Added the new enetc driver for NXP enetc platform. See the + "ENETC Poll Mode Driver" document for more details on this new driver. + +* **Added Ethernet poll mode driver for Aquantia aQtion family of 10G devices.** + + Added the new ``atlantic`` ethernet poll mode driver for Aquantia XGBE devices. + See the :doc:`../nics/atlantic` nic driver guide for more details on this + driver. + +* **Updated Solarflare network PMD.** + + Updated the sfc_efx driver including the following changes: + + * Added support for Rx scatter in EF10 datapath implementation. + * Added support for Rx descriptor status API in EF10 datapath implementation. + * Added support for TSO in EF10 datapath implementation. + * Added support for Tx descriptor status API in EF10 (ef10 and ef10_simple) + datapaths implementation. + +* **Updated the enic driver.** + + * Added AVX2-based vectorized Rx handler. + * Added VLAN and checksum offloads to the simple Tx handler. + * Added the count flow action. + * Enabled the virtual address IOVA mode. + +* **Updated failsafe driver.** + + Updated the failsafe driver including the following changes: + + * Support for Rx and Tx queues start and stop. + * Support for Rx and Tx queues deferred start. + * Support for runtime Rx and Tx queues setup. + * Support multicast MAC address set. + +* **Added a devarg to use PCAP interface physical MAC address.** + A new devarg ``phy_mac`` was introduced to allow users to use physical + MAC address of the selected PCAP interface. + +* **Added TAP Rx/Tx queues sharing with a secondary process.** + + A secondary process can attach a TAP device created in the primary process, + probe the queues, and process Rx/Tx in a secondary process. + +* **Added classification and metering support to SoftNIC PMD.** + + Added support for flow classification (rte_flow API), and metering and + policing (rte_mtr API) to the SoftNIC PMD. + +* **Added Crypto support to Softnic PMD.** + + The Softnic is now capable of processing symmetric crypto workloads such + as cipher, cipher-authentication chaining, and aead encryption and + decryption. This is achieved by calling DPDK Cryptodev APIs. + +* **Added cryptodev port to port library.** + + Cryptodev port is a shim layer in the port library that interacts with DPDK + Cryptodev PMDs including burst enqueuing and dequeuing crypto operations. + +* **Added symmetric cryptographic actions to the pipeline library.** + + In the pipeline library an added symmetric crypto action parsing and action + handler are implemented. The action allows automatically preparing the crypto + operation with the rules specified such as algorithm, key, and IV, etc for + the cryptodev port to process. + +* **Added support for GEN3 devices to Intel QAT driver .** + + Added support for the third generation of Intel QuickAssist devices. + +* **Updated the QAT PMD.** + + The QAT PMD was updated with additional support for: + + * AES-CMAC algorithm. + +* **Updated the AESNI MB PMD.** + + The AESNI MB PMD has been updated with additional support for AES-GCM + algorithm support. + +* **Added NXP CAAM JR PMD.** + + Added the new caam job ring driver for NXP platforms. See the + "NXP CAAM JOB RING (caam_jr)" document for more details on this new driver. + +* **Added support for Dynamic Huffman Encoding to Intel QAT comp PMD.** + + The Intel QuickAssist (QAT) compression PMD has been updated with support + for Dynamic Huffman Encoding for the Deflate algorithm. + +* **Added Event Ethernet Tx Adapter.** + + Added event ethernet Tx adapter library that provides configuration and + data path APIs for the ethernet transmit stage of an event driven packet + processing application. These APIs abstract the implementation of the + transmit stage and allow the application to use eventdev PMD support or + a common implementation. + +* **Added Distributed Software Eventdev PMD.** + + Added the new Distributed Software Event Device (DSW), which is a + pure-software eventdev driver distributing the work of scheduling + among all eventdev ports and the lcores using them. DSW, compared to + the SW eventdev PMD, sacrifices load balancing performance to + gain better event scheduling throughput and scalability. + +* **Added extendable bucket feature to hash library (rte_hash).** + + This new “extendable bucket” feature provides 100% insertion guarantee to + the capacity specified by the user by extending hash table with extra + buckets when needed to accommodate the unlikely event of intensive hash + collisions. In addition, the internal hashing algorithm was changed to use + partial-key hashing to improve memory efficiency and lookup performance. + +* **Added lock free reader/writer concurrency to hash library (rte_hash).** + + Lock free reader/writer concurrency prevents the readers from getting + blocked due to a pre-empted writer thread. This allows the hash library + to be used in scenarios where the writer thread runs on control plane. + +* **Added Traffic Pattern Aware Power Control Library** + + Added an experimental library. This extend Power Library and provide + empty_poll APIs. This feature measure how many times empty_poll are + executed per core, use the number of empty polls as a hint for system + power management. + + See the :doc:`../prog_guide/power_man` section of the DPDK Programmers + Guide document for more information. + +* **Added JSON power policy interface for containers.** + + Extended the Power Library and vm_power_manager sample app to allow power + policies to be submitted via a FIFO using JSON formatted strings. Previously + limited to Virtual Machines, this feature extends power policy functionality + to containers and host applications that need to have their cores frequency + controlled based on the rules contained in the policy. + +* **Added Telemetry API.** + + Added the telemetry API which allows applications to transparently expose + their telemetry via a UNIX socket in JSON. The JSON can be consumed by any + Service Assurance agent, such as CollectD. + +* **Added ability to switch queue deferred start flag on testpmd app.** + + Added a console command to testpmd app, giving ability to switch + ``rx_deferred_start`` or ``tx_deferred_start`` flag of the specified queue of + the specified port. The port must be stopped before the command call in order + to reconfigure queues. + +* **Add a new sample for vDPA** + + The vdpa sample application creates vhost-user sockets by using the + vDPA backend. vDPA stands for vhost Data Path Acceleration which utilizes + virtio ring compatible devices to serve virtio driver directly to enable + datapath acceleration. As vDPA driver can help to set up vhost datapath, + this application doesn't need to launch dedicated worker threads for vhost + enqueue/dequeue operations. + + +API Changes +----------- + +.. This section should contain API changes. Sample format: + + * Add a short 1-2 sentence description of the API change. + Use fixed width quotes for ``function_names`` or ``struct_names``. + Use the past tense. + + This section is a comment. Do not overwrite or remove it. + Also, make sure to start the actual text at the margin. + ========================================================= + +* eal: ``rte_memseg_list`` structure now has an additional flag indicating + whether the memseg list is externally allocated. This will have implications + for any users of memseg-walk-related functions, as they will now have to skip + externally allocated segments in most cases if the intent is to only iterate + over internal DPDK memory. + ``socket_id`` parameter across the entire DPDK has gained additional meaning, + as some socket ID's will now be representing externally allocated memory. No + changes will be required for existing code as backwards compatibility will be + kept, and those who do not use this feature will not see these extra socket + ID's. Any new API's must not check socket ID parameters themselves, and must + instead leave it to the memory subsystem to decide whether socket ID is a + valid one. + +* eal: The following devargs functions, which were deprecated in 18.05, + were removed in 18.11: + ``rte_eal_parse_devargs_str()``, ``rte_eal_devargs_add()``, + ``rte_eal_devargs_type_count()``, and ``rte_eal_devargs_dump()``. + +* eal: The parameters of the function ``rte_devargs_remove()`` have changed + from bus and device names to ``struct rte_devargs``. + +* eal: The deprecated functions attach/detach were removed in 18.11. + ``rte_eal_dev_attach`` can be replaced by + ``rte_dev_probe`` or ``rte_eal_hotplug_add``. + ``rte_eal_dev_detach`` can be replaced by + ``rte_dev_remove`` or ``rte_eal_hotplug_remove``. + +* eal: The scope of ``rte_eal_hotplug_add()``/``rte_dev_probe()`` + and ``rte_eal_hotplug_remove()``/``rte_dev_remove()`` is extended. + In multi-process model, they will guarantee that the device is + attached or detached on all processes. + +* mbuf: The ``__rte_mbuf_raw_free()`` and ``__rte_pktmbuf_prefree_seg()`` + functions were deprecated since 17.05 and are replaced by + ``rte_mbuf_raw_free()`` and ``rte_pktmbuf_prefree_seg()``. + +* ethdev: The deprecated functions attach/detach were removed in 18.11. + ``rte_eth_dev_attach`` can be replaced by ``RTE_ETH_FOREACH_MATCHING_DEV`` + and ``rte_dev_probe`` or ``rte_eal_hotplug_add``. + ``rte_eth_dev_detach`` can be replaced by + ``rte_dev_remove`` or ``rte_eal_hotplug_remove``. + +* ethdev: A call to ``rte_eth_dev_release_port()`` has been added in + ``rte_eth_dev_close()``. As a consequence, a closed port is freed + and seen as invalid because of its state ``RTE_ETH_DEV_UNUSED``. + This new behaviour is enabled per driver for a migration period. + +* A new device flag, RTE_ETH_DEV_NOLIVE_MAC_ADDR, changes the order of + actions inside rte_eth_dev_start regarding MAC set. Some NICs do not + support MAC changes once the port has started and with this new device + flag the MAC can be properly configured in any case. This is particularly + important for bonding. + +* The default behaviour of CRC strip offload changed. Without any specific Rx + offload flag, default behavior by PMD is now to strip CRC. + DEV_RX_OFFLOAD_CRC_STRIP offload flag has been removed. + To request keeping CRC, application should set ``DEV_RX_OFFLOAD_KEEP_CRC`` Rx + offload. + +* eventdev: Type of 2nd parameter to ``rte_event_eth_rx_adapter_caps_get()`` + has been changed from uint8_t to uint16_t. + + +ABI Changes +----------- + +.. This section should contain ABI changes. Sample format: + + * Add a short 1-2 sentence description of the ABI change + that was announced in the previous releases and made in this release. + Use fixed width quotes for ``function_names`` or ``struct_names``. + Use the past tense. + + This section is a comment. Do not overwrite or remove it. + Also, make sure to start the actual text at the margin. + ========================================================= + +* eal: added ``legacy_mem`` and ``single_file_segments`` values to + ``rte_config`` structure on account of improving DPDK usability when + using either ``--legacy-mem`` or ``--single-file-segments`` flags. + +* eal: EAL library ABI version was changed due to previously announced work on + supporting external memory in DPDK: + - structure ``rte_memseg_list`` now has a new field indicating length + of memory addressed by the segment list + - structure ``rte_memseg_list`` now has a new flag indicating whether + the memseg list refers to external memory + - structure ``rte_malloc_heap`` now has a new field indicating socket + ID the malloc heap belongs to + - structure ``rte_mem_config`` has had its ``malloc_heaps`` array + resized from ``RTE_MAX_NUMA_NODES`` to ``RTE_MAX_HEAPS`` value + - structure ``rte_malloc_heap`` now has a ``heap_name`` member + - structure ``rte_eal_memconfig`` has been extended to contain next + socket ID for externally allocated segments + +* eal: Added ``dma_maskbits`` to ``rte_mem_config`` for keeping more restricted + dma mask based on devices addressing limitations. + +* eal: The structure ``rte_device`` got a new field to reference a ``rte_bus``. + It is changing the size of the ``struct rte_device`` and the inherited + device structures of all buses. + + +Removed Items +------------- + +.. This section should contain removed items in this release. Sample format: + + * Add a short 1-2 sentence description of the removed item + in the past tense. + + This section is a comment. Do not overwrite or remove it. + Also, make sure to start the actual text at the margin. + ========================================================= + + +Shared Library Versions +----------------------- + +.. Update any library version updated in this release + and prepend with a ``+`` sign, like this: + + librte_acl.so.2 + + librte_cfgfile.so.2 + librte_cmdline.so.2 + + This section is a comment. Do not overwrite or remove it. + ========================================================= + +The libraries prepended with a plus sign were incremented in this version. + +.. code-block:: diff + + librte_acl.so.2 + librte_bbdev.so.1 + librte_bitratestats.so.2 + librte_bpf.so.1 + + librte_bus_dpaa.so.2 + + librte_bus_fslmc.so.2 + + librte_bus_ifpga.so.2 + + librte_bus_pci.so.2 + + librte_bus_vdev.so.2 + + librte_bus_vmbus.so.2 + librte_cfgfile.so.2 + librte_cmdline.so.2 + librte_compressdev.so.1 + librte_cryptodev.so.5 + librte_distributor.so.1 + + librte_eal.so.9 + librte_efd.so.1 + + librte_ethdev.so.11 + + librte_eventdev.so.6 + librte_flow_classify.so.1 + librte_gro.so.1 + librte_gso.so.1 + librte_hash.so.2 + librte_ip_frag.so.1 + librte_jobstats.so.1 + librte_kni.so.2 + librte_kvargs.so.1 + librte_latencystats.so.1 + librte_lpm.so.2 + librte_mbuf.so.4 + librte_member.so.1 + librte_mempool.so.5 + librte_meter.so.2 + librte_metrics.so.1 + librte_net.so.1 + librte_pci.so.1 + librte_pdump.so.2 + librte_pipeline.so.3 + librte_pmd_bnxt.so.2 + librte_pmd_bond.so.2 + librte_pmd_i40e.so.2 + librte_pmd_ixgbe.so.2 + librte_pmd_dpaa2_qdma.so.1 + librte_pmd_ring.so.2 + librte_pmd_softnic.so.1 + librte_pmd_vhost.so.2 + librte_port.so.3 + librte_power.so.1 + librte_rawdev.so.1 + librte_reorder.so.1 + librte_ring.so.2 + librte_sched.so.1 + librte_security.so.1 + librte_table.so.3 + librte_timer.so.1 + librte_vhost.so.4 + + +Known Issues +------------ + +.. This section should contain new known issues in this release. Sample format: + + * **Add title in present tense with full stop.** + + Add a short 1-2 sentence description of the known issue + in the present tense. Add information on any known workarounds. + + This section is a comment. Do not overwrite or remove it. + Also, make sure to start the actual text at the margin. + ========================================================= + +* When using SR-IOV (VF) support with netvsc PMD and the Mellanox mlx5 bifurcated + driver; the Linux netvsc device must be brought up before the netvsc device is + unbound and passed to the DPDK. + + +Tested Platforms +---------------- + +.. This section should contain a list of platforms that were tested + with this release. + + The format is: + + * <vendor> platform with <vendor> <type of devices> combinations + + * List of CPU + * List of OS + * List of devices + * Other relevant details... + + This section is a comment. Do not overwrite or remove it. + Also, make sure to start the actual text at the margin. + ========================================================= diff --git a/doc/guides/sample_app_ug/flow_filtering.rst b/doc/guides/sample_app_ug/flow_filtering.rst index bd0ae1e2..0d6fe2bb 100644 --- a/doc/guides/sample_app_ug/flow_filtering.rst +++ b/doc/guides/sample_app_ug/flow_filtering.rst @@ -139,7 +139,6 @@ application is shown below: struct rte_eth_conf port_conf = { .rxmode = { .split_hdr_size = 0, - .offloads = DEV_RX_OFFLOAD_CRC_STRIP, }, .txmode = { .offloads = @@ -215,7 +214,6 @@ The Ethernet port is configured with default settings using the struct rte_eth_conf port_conf = { .rxmode = { .split_hdr_size = 0, - .offloads = DEV_RX_OFFLOAD_CRC_STRIP, }, .txmode = { .offloads = diff --git a/doc/guides/sample_app_ug/index.rst b/doc/guides/sample_app_ug/index.rst index 5bedf4f6..74b12af8 100644 --- a/doc/guides/sample_app_ug/index.rst +++ b/doc/guides/sample_app_ug/index.rst @@ -45,6 +45,7 @@ Sample Applications User Guides vhost vhost_scsi vhost_crypto + vdpa netmap_compatibility ip_pipeline test_pipeline diff --git a/doc/guides/sample_app_ug/ip_pipeline.rst b/doc/guides/sample_app_ug/ip_pipeline.rst index b75509a0..447a544d 100644 --- a/doc/guides/sample_app_ug/ip_pipeline.rst +++ b/doc/guides/sample_app_ug/ip_pipeline.rst @@ -304,6 +304,15 @@ Kni [thread <thread_id>] +Cryptodev +~~~~~~~~~ + + Create cryptodev port :: + + cryptodev <cryptodev_name> + dev <DPDK Cryptodev PMD name> + queue <n_queues> <queue_size> + Action profile ~~~~~~~~~~~~~~ @@ -330,6 +339,8 @@ Action profile [ttl drop | fwd stats none | pkts] [stats pkts | bytes | both] + [sym_crypto cryptodev <cryptodev_name> + mempool_create <mempool_name> mempool_init <mempool_name>] [time] @@ -471,6 +482,18 @@ Add rule to table for specific pipeline instance :: [ttl dec | keep] [stats] [time] + [sym_crypto + encrypt | decrypt + type + | cipher + cipher_algo <algo> cipher_key <key> cipher_iv <iv> + | cipher_auth + cipher_algo <algo> cipher_key <key> cipher_iv <iv> + auth_algo <algo> auth_key <key> digest_size <size> + | aead + aead_algo <algo> aead_key <key> aead_iv <iv> aead_aad <aad> + digest_size <size> + data_offset <data_offset>] where: <pa> ::= g | y | r | drop diff --git a/doc/guides/sample_app_ug/ipsec_secgw.rst b/doc/guides/sample_app_ug/ipsec_secgw.rst index 46696f2a..4869a011 100644 --- a/doc/guides/sample_app_ug/ipsec_secgw.rst +++ b/doc/guides/sample_app_ug/ipsec_secgw.rst @@ -67,7 +67,7 @@ Constraints * No IPv6 options headers. * No AH mode. -* Supported algorithms: AES-CBC, AES-CTR, AES-GCM, HMAC-SHA1 and NULL. +* Supported algorithms: AES-CBC, AES-CTR, AES-GCM, 3DES-CBC, HMAC-SHA1 and NULL. * Each SA must be handle by a unique lcore (*1 RX queue per port*). * No chained mbufs. @@ -397,6 +397,7 @@ where each options means: * *aes-128-cbc*: AES-CBC 128-bit algorithm * *aes-256-cbc*: AES-CBC 256-bit algorithm * *aes-128-ctr*: AES-CTR 128-bit algorithm + * *3des-cbc*: 3DES-CBC 192-bit algorithm * Syntax: *cipher_algo <your algorithm>* diff --git a/doc/guides/sample_app_ug/kernel_nic_interface.rst b/doc/guides/sample_app_ug/kernel_nic_interface.rst index 1b3ee9a5..6acdf0ff 100644 --- a/doc/guides/sample_app_ug/kernel_nic_interface.rst +++ b/doc/guides/sample_app_ug/kernel_nic_interface.rst @@ -31,18 +31,27 @@ This is done by creating one or more kernel net devices for each of the DPDK por The application allows the use of standard Linux tools (ethtool, ifconfig, tcpdump) with the DPDK ports and also the exchange of packets between the DPDK application and the Linux* kernel. +The Kernel NIC Interface sample application requires that the +KNI kernel module ``rte_kni`` be loaded into the kernel. See +:doc:`../prog_guide/kernel_nic_interface` for more information on loading +the ``rte_kni`` kernel module. + Overview -------- -The Kernel NIC Interface sample application uses two threads in user space for each physical NIC port being used, -and allocates one or more KNI device for each physical NIC port with kernel module's support. -For a physical NIC port, one thread reads from the port and writes to KNI devices, -and another thread reads from KNI devices and writes the data unmodified to the physical NIC port. -It is recommended to configure one KNI device for each physical NIC port. -If configured with more than one KNI devices for a physical NIC port, -it is just for performance testing, or it can work together with VMDq support in future. +The Kernel NIC Interface sample application ``kni`` allocates one or more +KNI interfaces for each physical NIC port. For each physical NIC port, +``kni`` uses two DPDK threads in user space; one thread reads from the port and +writes to the corresponding KNI interfaces and the other thread reads from +the KNI interfaces and writes the data unmodified to the physical NIC port. + +It is recommended to configure one KNI interface for each physical NIC port. +The application can be configured with more than one KNI interface for +each physical NIC port for performance testing or it can work together with +VMDq support in future. -The packet flow through the Kernel NIC Interface application is as shown in the following figure. +The packet flow through the Kernel NIC Interface application is as shown +in the following figure. .. _figure_kernel_nic: @@ -50,145 +59,221 @@ The packet flow through the Kernel NIC Interface application is as shown in the Kernel NIC Application Packet Flow +If link monitoring is enabled with the ``-m`` command line flag, one +additional pthread is launched which will check the link status of each +physical NIC port and will update the carrier status of the corresponding +KNI interface(s) to match the physical NIC port's state. This means that +the KNI interface(s) will be disabled automatically when the Ethernet link +goes down and enabled when the Ethernet link goes up. + +If link monitoring is enabled, the ``rte_kni`` kernel module should be loaded +such that the :ref:`default carrier state <kni_default_carrier_state>` is +set to *off*. This ensures that the KNI interface is only enabled *after* +the Ethernet link of the corresponding NIC port has reached the linkup state. + +If link monitoring is not enabled, the ``rte_kni`` kernel module should be +loaded with the :ref:`default carrier state <kni_default_carrier_state>` +set to *on*. This sets the carrier state of the KNI interfaces to *on* +when the KNI interfaces are enabled without regard to the actual link state +of the corresponding NIC port. This is useful for testing in loopback +mode where the NIC port may not be physically connected to anything. + Compiling the Application ------------------------- To compile the sample application see :doc:`compiling`. -The application is located in the ``kni`` sub-directory. +The application is located in the ``examples/kni`` sub-directory. .. note:: This application is intended as a linuxapp only. -Loading the Kernel Module -------------------------- +Running the kni Example Application +----------------------------------- -Loading the KNI kernel module without any parameter is the typical way a DPDK application -gets packets into and out of the kernel net stack. -This way, only one kernel thread is created for all KNI devices for packet receiving in kernel side: +The ``kni`` example application requires a number of command line options: .. code-block:: console - #insmod rte_kni.ko + kni [EAL options] -- -p PORTMASK --config="(port,lcore_rx,lcore_tx[,lcore_kthread,...])[,(port,lcore_rx,lcore_tx[,lcore_kthread,...])]" [-P] [-m] -Pinning the kernel thread to a specific core can be done using a taskset command such as following: +Where: -.. code-block:: console +* ``-p PORTMASK``: - #taskset -p 100000 `pgrep --fl kni_thread | awk '{print $1}'` + Hexadecimal bitmask of ports to configure. -This command line tries to pin the specific kni_thread on the 20th lcore (lcore numbering starts at 0), -which means it needs to check if that lcore is available on the board. -This command must be sent after the application has been launched, as insmod does not start the kni thread. +* ``--config="(port,lcore_rx,lcore_tx[,lcore_kthread,...])[,(port,lcore_rx,lcore_tx[,lcore_kthread,...])]"``: -For optimum performance, -the lcore in the mask must be selected to be on the same socket as the lcores used in the KNI application. + Determines which lcores the Rx and Tx DPDK tasks, and (optionally) + the KNI kernel thread(s) are bound to for each physical port. -To provide flexibility of performance, the kernel module of the KNI, -located in the kmod sub-directory of the DPDK target directory, -can be loaded with parameter of kthread_mode as follows: +* ``-P``: -* #insmod rte_kni.ko kthread_mode=single + Optional flag to set all ports to promiscuous mode so that packets are + accepted regardless of the packet's Ethernet MAC destination address. + Without this option, only packets with the Ethernet MAC destination + address set to the Ethernet address of the port are accepted. - This mode will create only one kernel thread for all KNI devices for packet receiving in kernel side. - By default, it is in this single kernel thread mode. - It can set core affinity for this kernel thread by using Linux command taskset. +* ``-m``: -* #insmod rte_kni.ko kthread_mode =multiple + Optional flag to enable monitoring and updating of the Ethernet + carrier state. With this option set, a thread will be started which + will periodically check the Ethernet link status of the physical + Ethernet ports and set the carrier state of the corresponding KNI + network interface to match it. This means that the KNI interface will + be disabled automatically when the Ethernet link goes down and enabled + when the Ethernet link goes up. - This mode will create a kernel thread for each KNI device for packet receiving in kernel side. - The core affinity of each kernel thread is set when creating the KNI device. - The lcore ID for each kernel thread is provided in the command line of launching the application. - Multiple kernel thread mode can provide scalable higher performance. +Refer to *DPDK Getting Started Guide* for general information on running +applications and the Environment Abstraction Layer (EAL) options. -To measure the throughput in a loopback mode, the kernel module of the KNI, -located in the kmod sub-directory of the DPDK target directory, -can be loaded with parameters as follows: +The ``-c coremask`` or ``-l corelist`` parameter of the EAL options must +include the lcores specified by ``lcore_rx`` and ``lcore_tx`` for each port, +but does not need to include lcores specified by ``lcore_kthread`` as those +cores are used to pin the kernel threads in the ``rte_kni`` kernel module. -* #insmod rte_kni.ko lo_mode=lo_mode_fifo +The ``--config`` parameter must include a set of +``(port,lcore_rx,lcore_tx,[lcore_kthread,...])`` values for each physical +port specified in the ``-p PORTMASK`` parameter. - This loopback mode will involve ring enqueue/dequeue operations in kernel space. +The optional ``lcore_kthread`` lcore ID parameter in ``--config`` can be +specified zero, one or more times for each physical port. -* #insmod rte_kni.ko lo_mode=lo_mode_fifo_skb +If no lcore ID is specified for ``lcore_kthread``, one KNI interface will +be created for the physical port ``port`` and the KNI kernel thread(s) +will have no specific core affinity. - This loopback mode will involve ring enqueue/dequeue operations and sk buffer copies in kernel space. +If one or more lcore IDs are specified for ``lcore_kthread``, a KNI interface +will be created for each lcore ID specified, bound to the physical port +``port``. If the ``rte_kni`` kernel module is loaded in :ref:`multiple +kernel thread <kni_kernel_thread_mode>` mode, a kernel thread will be created +for each KNI interface and bound to the specified core. If the ``rte_kni`` +kernel module is loaded in :ref:`single kernel thread <kni_kernel_thread_mode>` +mode, only one kernel thread is started for all KNI interfaces. The kernel +thread will be bound to the first ``lcore_kthread`` lcore ID specified. -Running the Application ------------------------ +Example Configurations +~~~~~~~~~~~~~~~~~~~~~~~ -The application requires a number of command line options: +The following commands will first load the ``rte_kni`` kernel module in +:ref:`multiple kernel thread <kni_kernel_thread_mode>` mode. The ``kni`` +application is then started using two ports; Port 0 uses lcore 4 for the +Rx task, lcore 6 for the Tx task, and will create a single KNI interface +``vEth0_0`` with the kernel thread bound to lcore 8. Port 1 uses lcore +5 for the Rx task, lcore 7 for the Tx task, and will create a single KNI +interface ``vEth1_0`` with the kernel thread bound to lcore 9. .. code-block:: console - kni [EAL options] -- -P -p PORTMASK --config="(port,lcore_rx,lcore_tx[,lcore_kthread,...])[,port,lcore_rx,lcore_tx[,lcore_kthread,...]]" - -Where: + # rmmod rte_kni + # insmod kmod/rte_kni.ko kthread_mode=multiple + # ./build/kni -l 4-7 -n 4 -- -P -p 0x3 -m --config="(0,4,6,8),(1,5,7,9)" -* -P: Set all ports to promiscuous mode so that packets are accepted regardless of the packet's Ethernet MAC destination address. - Without this option, only packets with the Ethernet MAC destination address set to the Ethernet address of the port are accepted. +The following example is identical, except an additional ``lcore_kthread`` +core is specified per physical port. In this case, ``kni`` will create +four KNI interfaces: ``vEth0_0``/``vEth0_1`` bound to physical port 0 and +``vEth1_0``/``vEth1_1`` bound to physical port 1. -* -p PORTMASK: Hexadecimal bitmask of ports to configure. +The kernel thread for each interface will be bound as follows: -* --config="(port,lcore_rx, lcore_tx[,lcore_kthread, ...]) [, port,lcore_rx, lcore_tx[,lcore_kthread, ...]]": - Determines which lcores of RX, TX, kernel thread are mapped to which ports. + * ``vEth0_0`` - bound to lcore 8. + * ``vEth0_1`` - bound to lcore 10. + * ``vEth1_0`` - bound to lcore 9. + * ``vEth1_1`` - bound to lcore 11 -Refer to *DPDK Getting Started Guide* for general information on running applications and the Environment Abstraction Layer (EAL) options. +.. code-block:: console -The -c coremask or -l corelist parameter of the EAL options should include the lcores indicated by the lcore_rx and lcore_tx, -but does not need to include lcores indicated by lcore_kthread as they are used to pin the kernel thread on. -The -p PORTMASK parameter should include the ports indicated by the port in --config, neither more nor less. + # rmmod rte_kni + # insmod kmod/rte_kni.ko kthread_mode=multiple + # ./build/kni -l 4-7 -n 4 -- -P -p 0x3 -m --config="(0,4,6,8,10),(1,5,7,9,11)" -The lcore_kthread in --config can be configured none, one or more lcore IDs. -In multiple kernel thread mode, if configured none, a KNI device will be allocated for each port, -while no specific lcore affinity will be set for its kernel thread. -If configured one or more lcore IDs, one or more KNI devices will be allocated for each port, -while specific lcore affinity will be set for its kernel thread. -In single kernel thread mode, if configured none, a KNI device will be allocated for each port. -If configured one or more lcore IDs, -one or more KNI devices will be allocated for each port while -no lcore affinity will be set as there is only one kernel thread for all KNI devices. +The following example can be used to test the interface between the ``kni`` +test application and the ``rte_kni`` kernel module. In this example, +the ``rte_kni`` kernel module is loaded in :ref:`single kernel thread +mode <kni_kernel_thread_mode>`, :ref:`loopback mode <kni_loopback_mode>` +enabled, and the :ref:`default carrier state <kni_default_carrier_state>` +is set to *on* so that the corresponding physical NIC port does not have +to be connected in order to use the KNI interface. One KNI interface +``vEth0_0`` is created for port 0 and one KNI interface ``vEth1_0`` is +created for port 1. Since ``rte_kni`` is loaded in "single kernel thread" +mode, the one kernel thread is bound to lcore 8. -For example, to run the application with two ports served by six lcores, one lcore of RX, one lcore of TX, -and one lcore of kernel thread for each port: +Since the physical NIC ports are not being used, link monitoring can be +disabled by **not** specifying the ``-m`` flag to ``kni``: .. code-block:: console - ./build/kni -l 4-7 -n 4 -- -P -p 0x3 --config="(0,4,6,8),(1,5,7,9)" + # rmmod rte_kni + # insmod kmod/rte_kni.ko lo_mode=lo_mode_fifo carrier=on + # ./build/kni -l 4-7 -n 4 -- -P -p 0x3 --config="(0,4,6,8),(1,5,7,9)" KNI Operations -------------- -Once the KNI application is started, one can use different Linux* commands to manage the net interfaces. -If more than one KNI devices configured for a physical port, -only the first KNI device will be paired to the physical device. -Operations on other KNI devices will not affect the physical port handled in user space application. +Once the ``kni`` application is started, the user can use the normal +Linux commands to manage the KNI interfaces as if they were any other +Linux network interface. -Assigning an IP address: +Enable KNI interface and assign an IP address: .. code-block:: console - #ifconfig vEth0_0 192.168.0.1 + # ifconfig vEth0_0 192.168.0.1 -Displaying the NIC registers: +Show KNI interface configuration and statistics: .. code-block:: console - #ethtool -d vEth0_0 + # ifconfig vEth0_0 + +The user can also check and reset the packet statistics inside the ``kni`` +application by sending the app the USR1 and USR2 signals: + +.. code-block:: console + + # Print statistics + # kill -SIGUSR1 `pidof kni` + + # Zero statistics + # kill -SIGUSR2 `pidof kni` -Dumping the network traffic: +Dump network traffic: .. code-block:: console - #tcpdump -i vEth0_0 + # tcpdump -i vEth0_0 + +The normal Linux commands can also be used to change the MAC address and +MTU size used by the physical NIC which corresponds to the KNI interface. +However, if more than one KNI interface is configured for a physical port, +these commands will only work on the first KNI interface for that port. Change the MAC address: .. code-block:: console - #ifconfig vEth0_0 hw ether 0C:01:02:03:04:08 + # ifconfig vEth0_0 hw ether 0C:01:02:03:04:08 + +Change the MTU size: + +.. code-block:: console + + # ifconfig vEth0_0 mtu 1450 + +If DPDK is compiled with ``CONFIG_RTE_KNI_KMOD_ETHTOOL=y`` and an Intel +NIC is used, the user can use ``ethtool`` on the KNI interface as if it +were a normal Linux kernel interface. + +Displaying the NIC registers: + +.. code-block:: console + + # ethtool -d vEth0_0 -When the DPDK userspace application is closed, all the KNI devices are deleted from Linux*. +When the ``kni`` application is closed, all the KNI interfaces are deleted +from the Linux kernel. Explanation ----------- @@ -227,7 +312,7 @@ to see if this lcore is reading from or writing to kernel NIC interfaces. For the case that reads from a NIC port and writes to the kernel NIC interfaces (``kni_ingress``), the packet reception is the same as in L2 Forwarding sample application (see :ref:`l2_fwd_app_rx_tx_packets`). -The packet transmission is done by sending mbufs into the kernel NIC interfaces by rte_kni_tx_burst(). +The packet transmission is done by sending mbufs into the kernel NIC interfaces by ``rte_kni_tx_burst()``. The KNI library automatically frees the mbufs after the kernel successfully copied the mbufs. For the other case that reads from kernel NIC interfaces @@ -235,16 +320,3 @@ and writes to a physical NIC port (``kni_egress``), packets are retrieved by reading mbufs from kernel NIC interfaces by ``rte_kni_rx_burst()``. The packet transmission is the same as in the L2 Forwarding sample application (see :ref:`l2_fwd_app_rx_tx_packets`). - -Callbacks for Kernel Requests -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -To execute specific PMD operations in user space requested by some Linux* commands, -callbacks must be implemented and filled in the struct rte_kni_ops structure. -Currently, setting a new MTU, change in MAC address, configuring promiscusous mode and -configuring the network interface(up/down) re supported. -Default implementation for following is available in rte_kni library. -Application may choose to not implement following callbacks: - -- ``config_mac_address`` -- ``config_promiscusity`` diff --git a/doc/guides/sample_app_ug/l3_forward_power_man.rst b/doc/guides/sample_app_ug/l3_forward_power_man.rst index 795a570b..e44a11b2 100644 --- a/doc/guides/sample_app_ug/l3_forward_power_man.rst +++ b/doc/guides/sample_app_ug/l3_forward_power_man.rst @@ -105,6 +105,8 @@ where, * --no-numa: optional, disables numa awareness +* --empty-poll: Traffic Aware power management. See below for details + See :doc:`l3_forward` for details. The L3fwd-power example reuses the L3fwd command line options. @@ -362,3 +364,70 @@ The algorithm has the following sleeping behavior depending on the idle counter: If a thread polls multiple Rx queues and different queue returns different sleep duration values, the algorithm controls the sleep time in a conservative manner by sleeping for the least possible time in order to avoid a potential performance impact. + +Empty Poll Mode +------------------------- +Additionally, there is a traffic aware mode of operation called "Empty +Poll" where the number of empty polls can be monitored to keep track +of how busy the application is. Empty poll mode can be enabled by the +command line option --empty-poll. + +See :doc:`Power Management<../prog_guide/power_man>` chapter in the DPDK Programmer's Guide for empty poll mode details. + +.. code-block:: console + + ./l3fwd-power -l xxx -n 4 -w 0000:xx:00.0 -w 0000:xx:00.1 -- -p 0x3 -P --config="(0,0,xx),(1,0,xx)" --empty-poll="0,0,0" -l 14 -m 9 -h 1 + +Where, + +--empty-poll: Enable the empty poll mode instead of original algorithm + +--empty-poll="training_flag, med_threshold, high_threshold" + +* ``training_flag`` : optional, enable/disable training mode. Default value is 0. If the training_flag is set as 1(true), then the application will start in training mode and print out the trained threshold values. If the training_flag is set as 0(false), the application will start in normal mode, and will use either the default thresholds or those supplied on the command line. The trained threshold values are specific to the user’s system, may give a better power profile when compared to the default threshold values. + +* ``med_threshold`` : optional, sets the empty poll threshold of a modestly busy system state. If this is not supplied, the application will apply the default value of 350000. + +* ``high_threshold`` : optional, sets the empty poll threshold of a busy system state. If this is not supplied, the application will apply the default value of 580000. + +* -l : optional, set up the LOW power state frequency index + +* -m : optional, set up the MED power state frequency index + +* -h : optional, set up the HIGH power state frequency index + +Empty Poll Mode Example Usage +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +To initially obtain the ideal thresholds for the system, the training +mode should be run first. This is achieved by running the l3fwd-power +app with the training flag set to “1”, and the other parameters set to +0. + +.. code-block:: console + + ./examples/l3fwd-power/build/l3fwd-power -l 1-3 -- -p 0x0f --config="(0,0,2),(0,1,3)" --empty-poll "1,0,0" –P + +This will run the training algorithm for x seconds on each core (cores 2 +and 3), and then print out the recommended threshold values for those +cores. The thresholds should be very similar for each core. + +.. code-block:: console + + POWER: Bring up the Timer + POWER: set the power freq to MED + POWER: Low threshold is 230277 + POWER: MED threshold is 335071 + POWER: HIGH threshold is 523769 + POWER: Training is Complete for 2 + POWER: set the power freq to MED + POWER: Low threshold is 236814 + POWER: MED threshold is 344567 + POWER: HIGH threshold is 538580 + POWER: Training is Complete for 3 + +Once the values have been measured for a particular system, the app can +then be started without the training mode so traffic can start immediately. + +.. code-block:: console + + ./examples/l3fwd-power/build/l3fwd-power -l 1-3 -- -p 0x0f --config="(0,0,2),(0,1,3)" --empty-poll "0,340000,540000" –P diff --git a/doc/guides/sample_app_ug/link_status_intr.rst b/doc/guides/sample_app_ug/link_status_intr.rst index c7665fe5..695c088e 100644 --- a/doc/guides/sample_app_ug/link_status_intr.rst +++ b/doc/guides/sample_app_ug/link_status_intr.rst @@ -137,7 +137,6 @@ The global configuration is stored in a static structure: static const struct rte_eth_conf port_conf = { .rxmode = { .split_hdr_size = 0, - .offloads = DEV_RX_OFFLOAD_CRC_STRIP, }, .txmode = {}, .intr_conf = { diff --git a/doc/guides/sample_app_ug/vdpa.rst b/doc/guides/sample_app_ug/vdpa.rst new file mode 100644 index 00000000..745f196c --- /dev/null +++ b/doc/guides/sample_app_ug/vdpa.rst @@ -0,0 +1,120 @@ +.. SPDX-License-Identifier: BSD-3-Clause + Copyright(c) 2018 Intel Corporation. + +Vdpa Sample Application +======================= + +The vdpa sample application creates vhost-user sockets by using the +vDPA backend. vDPA stands for vhost Data Path Acceleration which utilizes +virtio ring compatible devices to serve virtio driver directly to enable +datapath acceleration. As vDPA driver can help to set up vhost datapath, +this application doesn't need to launch dedicated worker threads for vhost +enqueue/dequeue operations. + +Testing steps +------------- + +This section shows the steps of how to start VMs with vDPA vhost-user +backend and verify network connection & live migration. + +Build +~~~~~ + +To compile the sample application see :doc:`compiling`. + +The application is located in the ``vdpa`` sub-directory. + +Start the vdpa example +~~~~~~~~~~~~~~~~~~~~~~ + +.. code-block:: console + + ./vdpa [EAL options] -- [--client] [--interactive|-i] or [--iface SOCKET_PATH] + +where + +* --client means running vdpa app in client mode, in the client mode, QEMU needs + to run as the server mode and take charge of socket file creation. +* --iface specifies the path prefix of the UNIX domain socket file, e.g. + /tmp/vhost-user-, then the socket files will be named as /tmp/vhost-user-<n> + (n starts from 0). +* --interactive means run the vdpa sample in interactive mode, currently 4 + internal cmds are supported: + + 1. help: show help message + 2. list: list all available vdpa devices + 3. create: create a new vdpa port with socket file and vdpa device address + 4. quit: unregister vhost driver and exit the application + +Take IFCVF driver for example: + +.. code-block:: console + + ./vdpa -c 0x2 -n 4 --socket-mem 1024,1024 \ + -w 0000:06:00.3,vdpa=1 -w 0000:06:00.4,vdpa=1 \ + -- --interactive + +.. note:: + Here 0000:06:00.3 and 0000:06:00.4 refer to virtio ring compatible devices, + and we need to bind vfio-pci to them before running vdpa sample. + + * modprobe vfio-pci + * ./usertools/dpdk-devbind.py -b vfio-pci 06:00.3 06:00.4 + +Then we can create 2 vdpa ports in interactive cmdline. + +.. code-block:: console + + vdpa> list + device id device address queue num supported features + 0 0000:06:00.3 1 0x14c238020 + 1 0000:06:00.4 1 0x14c238020 + 2 0000:06:00.5 1 0x14c238020 + + vdpa> create /tmp/vdpa-socket0 0000:06:00.3 + vdpa> create /tmp/vdpa-socket1 0000:06:00.4 + +.. _vdpa_app_run_vm: + +Start the VMs +~~~~~~~~~~~~~ + +.. code-block:: console + + qemu-system-x86_64 -cpu host -enable-kvm \ + <snip> + -mem-prealloc \ + -chardev socket,id=char0,path=<socket_file created in above steps> \ + -netdev type=vhost-user,id=vdpa,chardev=char0 \ + -device virtio-net-pci,netdev=vdpa,mac=00:aa:bb:cc:dd:ee,page-per-vq=on \ + +After the VMs launches, we can login the VMs and configure the ip, verify the +network connection via ping or netperf. + +.. note:: + Suggest to use QEMU 3.0.0 which extends vhost-user for vDPA. + +Live Migration +~~~~~~~~~~~~~~ +vDPA supports cross-backend live migration, user can migrate SW vhost backend +VM to vDPA backend VM and vice versa. Here are the detailed steps. Assume A is +the source host with SW vhost VM and B is the destination host with vDPA. + +1. Start vdpa sample and launch a VM with exact same parameters as the VM on A, + in migration-listen mode: + +.. code-block:: console + + B: <qemu-command-line> -incoming tcp:0:4444 (or other PORT)) + +2. Start the migration (on source host): + +.. code-block:: console + + A: (qemu) migrate -d tcp:<B ip>:4444 (or other PORT) + +3. Check the status (on source host): + +.. code-block:: console + + A: (qemu) info migrate diff --git a/doc/guides/sample_app_ug/vhost.rst b/doc/guides/sample_app_ug/vhost.rst index fd42cb3f..df4d6f9a 100644 --- a/doc/guides/sample_app_ug/vhost.rst +++ b/doc/guides/sample_app_ug/vhost.rst @@ -78,7 +78,7 @@ could be done by: .. code-block:: console modprobe uio_pci_generic - $RTE_SDK/usertools/dpdk-devbind.py -b=uio_pci_generic 0000:00:04.0 + $RTE_SDK/usertools/dpdk-devbind.py -b uio_pci_generic 0000:00:04.0 Then start testpmd for packet forwarding testing. diff --git a/doc/guides/sample_app_ug/vhost_crypto.rst b/doc/guides/sample_app_ug/vhost_crypto.rst index 65c86a53..3db57eab 100644 --- a/doc/guides/sample_app_ug/vhost_crypto.rst +++ b/doc/guides/sample_app_ug/vhost_crypto.rst @@ -28,24 +28,22 @@ Start the vhost_crypto example .. code-block:: console - ./vhost_crypto [EAL options] -- [--socket-file PATH] - [--cdev-id ID] [--cdev-queue-id ID] [--zero-copy] [--guest-polling] + ./vhost_crypto [EAL options] -- + --config (lcore,cdev-id,queue-id)[,(lcore,cdev-id,queue-id)] + --socketfile lcore,PATH + [--zero-copy] + [--guest-polling] where, -* socket-file PATH: the path of UNIX socket file to be created, multiple - instances of this config item is supported. Upon absence of this item, - the default socket-file `/tmp/vhost_crypto1.socket` is used. +* config (lcore,cdev-id,queue-id): build the lcore-cryptodev id-queue id + connection. Once specified, the specified lcore will only work with + specified cryptodev's queue. -* cdev-id ID: the target DPDK Cryptodev's ID to process the actual crypto - workload. Upon absence of this item the default value of `0` will be used. - For details of DPDK Cryptodev, please refer to DPDK Cryptodev Library - Programmers' Guide. - -* cdev-queue-id ID: the target DPDK Cryptodev's queue ID to process the - actual crypto workload. Upon absence of this item the default value of `0` - will be used. For details of DPDK Cryptodev, please refer to DPDK Cryptodev - Library Programmers' Guide. +* socket-file lcore,PATH: the path of UNIX socket file to be created and + the lcore id that will deal with the all workloads of the socket. Multiple + instances of this config item is supported and one lcore supports processing + multiple sockets. * zero-copy: the presence of this item means the ZERO-COPY feature will be enabled. Otherwise it is disabled. PLEASE NOTE the ZERO-COPY feature is still diff --git a/doc/guides/sample_app_ug/vm_power_management.rst b/doc/guides/sample_app_ug/vm_power_management.rst index 855570d6..1ad4f149 100644 --- a/doc/guides/sample_app_ug/vm_power_management.rst +++ b/doc/guides/sample_app_ug/vm_power_management.rst @@ -199,7 +199,7 @@ see :doc:`compiling`. The application is located in the ``vm_power_manager`` sub-directory. -To build just the ``vm_power_manager`` application: +To build just the ``vm_power_manager`` application using ``make``: .. code-block:: console @@ -208,6 +208,22 @@ To build just the ``vm_power_manager`` application: cd ${RTE_SDK}/examples/vm_power_manager/ make +The resulting binary will be ${RTE_SDK}/build/examples/vm_power_manager + +To build just the ``vm_power_manager`` application using ``meson/ninja``: + +.. code-block:: console + + export RTE_SDK=/path/to/rte_sdk + cd ${RTE_SDK} + meson build + cd build + ninja + meson configure -Dexamples=vm_power_manager + ninja + +The resulting binary will be ${RTE_SDK}/build/examples/dpdk-vm_power_manager + Running ~~~~~~~ @@ -337,6 +353,270 @@ monitoring of branch ratio on cores doing busy polling via PMDs. and will need to be adjusted for different workloads. + +JSON API +~~~~~~~~ + +In addition to the command line interface for host command and a virtio-serial +interface for VM power policies, there is also a JSON interface through which +power commands and policies can be sent. This functionality adds a dependency +on the Jansson library, and the Jansson development package must be installed +on the system before the JSON parsing functionality is included in the app. +This is achieved by: + + .. code-block:: javascript + + apt-get install libjansson-dev + +The command and package name may be different depending on your operating +system. It's worth noting that the app will successfully build without this +package present, but a warning is shown during compilation, and the JSON +parsing functionality will not be present in the app. + +Sending a command or policy to the power manager application is achieved by +simply opening a fifo file, writing a JSON string to that fifo, and closing +the file. + +The fifo is at /tmp/powermonitor/fifo + +The jason string can be a policy or instruction, and takes the following +format: + + .. code-block:: javascript + + {"packet_type": { + "pair_1": value, + "pair_2": value + }} + +The 'packet_type' header can contain one of two values, depending on +whether a policy or power command is being sent. The two possible values are +"policy" and "instruction", and the expected name-value pairs is different +depending on which type is being sent. + +The pairs are the format of standard JSON name-value pairs. The value type +varies between the different name/value pairs, and may be integers, strings, +arrays, etc. Examples of policies follow later in this document. The allowed +names and value types are as follows: + + +:Pair Name: "name" +:Description: Name of the VM or Host. Allows the parser to associate the + policy with the relevant VM or Host OS. +:Type: string +:Values: any valid string +:Required: yes +:Example: + + .. code-block:: javascript + + "name", "ubuntu2" + + +:Pair Name: "command" +:Description: The type of packet we're sending to the power manager. We can be + creating or destroying a policy, or sending a direct command to adjust + the frequency of a core, similar to the command line interface. +:Type: string +:Values: + + :CREATE: used when creating a new policy, + :DESTROY: used when removing a policy, + :POWER: used when sending an immediate command, max, min, etc. +:Required: yes +:Example: + + .. code-block:: javascript + + "command", "CREATE" + + +:Pair Name: "policy_type" +:Description: Type of policy to apply. Please see vm_power_manager documentation + for more information on the types of policies that may be used. +:Type: string +:Values: + + :TIME: Time-of-day policy. Frequencies of the relevant cores are + scaled up/down depending on busy and quiet hours. + :TRAFFIC: This policy takes statistics from the NIC and scales up + and down accordingly. + :WORKLOAD: This policy looks at how heavily loaded the cores are, + and scales up and down accordingly. + :BRANCH_RATIO: This out-of-band policy can look at the ratio between + branch hits and misses on a core, and is useful for detecting + how much packet processing a core is doing. +:Required: only for CREATE/DESTROY command +:Example: + + .. code-block:: javascript + + "policy_type", "TIME" + +:Pair Name: "busy_hours" +:Description: The hours of the day in which we scale up the cores for busy + times. +:Type: array of integers +:Values: array with list of hour numbers, (0-23) +:Required: only for TIME policy +:Example: + + .. code-block:: javascript + + "busy_hours":[ 17, 18, 19, 20, 21, 22, 23 ] + +:Pair Name: "quiet_hours" +:Description: The hours of the day in which we scale down the cores for quiet + times. +:Type: array of integers +:Values: array with list of hour numbers, (0-23) +:Required: only for TIME policy +:Example: + + .. code-block:: javascript + + "quiet_hours":[ 2, 3, 4, 5, 6 ] + +:Pair Name: "avg_packet_thresh" +:Description: Threshold below which the frequency will be set to min for + the TRAFFIC policy. If the traffic rate is above this and below max, the + frequency will be set to medium. +:Type: integer +:Values: The number of packets below which the TRAFFIC policy applies the + minimum frequency, or medium frequency if between avg and max thresholds. +:Required: only for TRAFFIC policy +:Example: + + .. code-block:: javascript + + "avg_packet_thresh": 100000 + +:Pair Name: "max_packet_thresh" +:Description: Threshold above which the frequency will be set to max for + the TRAFFIC policy +:Type: integer +:Values: The number of packets per interval above which the TRAFFIC policy + applies the maximum frequency +:Required: only for TRAFFIC policy +:Example: + + .. code-block:: javascript + + "max_packet_thresh": 500000 + +:Pair Name: "core_list" +:Description: The cores to which to apply the policy. +:Type: array of integers +:Values: array with list of virtual CPUs. +:Required: only policy CREATE/DESTROY +:Example: + + .. code-block:: javascript + + "core_list":[ 10, 11 ] + +:Pair Name: "workload" +:Description: When our policy is of type WORKLOAD, we need to specify how + heavy our workload is. +:Type: string +:Values: + + :HIGH: For cores running workloads that require high frequencies + :MEDIUM: For cores running workloads that require medium frequencies + :LOW: For cores running workloads that require low frequencies +:Required: only for WORKLOAD policy types +:Example: + + .. code-block:: javascript + + "workload", "MEDIUM" + +:Pair Name: "mac_list" +:Description: When our policy is of type TRAFFIC, we need to specify the + MAC addresses that the host needs to monitor +:Type: string +:Values: array with a list of mac address strings. +:Required: only for TRAFFIC policy types +:Example: + + .. code-block:: javascript + + "mac_list":[ "de:ad:be:ef:01:01", "de:ad:be:ef:01:02" ] + +:Pair Name: "unit" +:Description: the type of power operation to apply in the command +:Type: string +:Values: + + :SCALE_MAX: Scale frequency of this core to maximum + :SCALE_MIN: Scale frequency of this core to minimum + :SCALE_UP: Scale up frequency of this core + :SCALE_DOWN: Scale down frequency of this core + :ENABLE_TURBO: Enable Turbo Boost for this core + :DISABLE_TURBO: Disable Turbo Boost for this core +:Required: only for POWER instruction +:Example: + + .. code-block:: javascript + + "unit", "SCALE_MAX" + +:Pair Name: "resource_id" +:Description: The core to which to apply the power command. +:Type: integer +:Values: valid core id for VM or host OS. +:Required: only POWER instruction +:Example: + + .. code-block:: javascript + + "resource_id": 10 + +JSON API Examples +~~~~~~~~~~~~~~~~~ + +Profile create example: + + .. code-block:: javascript + + {"policy": { + "name": "ubuntu", + "command": "create", + "policy_type": "TIME", + "busy_hours":[ 17, 18, 19, 20, 21, 22, 23 ], + "quiet_hours":[ 2, 3, 4, 5, 6 ], + "core_list":[ 11 ] + }} + +Profile destroy example: + + .. code-block:: javascript + + {"profile": { + "name": "ubuntu", + "command": "destroy", + }} + +Power command example: + + .. code-block:: javascript + + {"command": { + "name": "ubuntu", + "unit": "SCALE_MAX", + "resource_id": 10 + }} + +To send a JSON string to the Power Manager application, simply paste the +example JSON string into a text file and cat it into the fifo: + + .. code-block:: console + + cat file.json >/tmp/powermonitor/fifo + +The console of the Power Manager application should indicate the command that +was just received via the fifo. + Compiling and Running the Guest Applications -------------------------------------------- @@ -366,7 +646,7 @@ For compiling and running l3fwd-power, see :doc:`l3_forward_power_man`. The application is located in the ``guest_cli`` sub-directory under ``vm_power_manager``. -To build just the ``guest_vm_power_manager`` application: +To build just the ``guest_vm_power_manager`` application using ``make``: .. code-block:: console @@ -375,6 +655,22 @@ To build just the ``guest_vm_power_manager`` application: cd ${RTE_SDK}/examples/vm_power_manager/guest_cli/ make +The resulting binary will be ${RTE_SDK}/build/examples/guest_cli + +To build just the ``vm_power_manager`` application using ``meson/ninja``: + +.. code-block:: console + + export RTE_SDK=/path/to/rte_sdk + cd ${RTE_SDK} + meson build + cd build + ninja + meson configure -Dexamples=vm_power_manager/guest_cli + ninja + +The resulting binary will be ${RTE_SDK}/build/examples/guest_cli + Running ~~~~~~~ diff --git a/doc/guides/testpmd_app_ug/run_app.rst b/doc/guides/testpmd_app_ug/run_app.rst index f301c2b6..c79fd0d0 100644 --- a/doc/guides/testpmd_app_ug/run_app.rst +++ b/doc/guides/testpmd_app_ug/run_app.rst @@ -133,6 +133,10 @@ See the DPDK Getting Started Guides for more information on these options. Use malloc instead of hugetlbfs. +* ``--iova-mode <pa|va>`` + + Force IOVA mode to a specific value. + Testpmd Command-line Options ---------------------------- @@ -332,7 +336,7 @@ The commandline options are: io (the default) mac - mac_swap + macswap flowgen rxonly txonly @@ -340,6 +344,7 @@ The commandline options are: icmpecho ieee1588 tm + noisy * ``--rss-ip`` @@ -498,3 +503,47 @@ The commandline options are: * ``--no-mlockall`` Disable locking all memory. + +* ``--mp-alloc <native|anon|xmem|xmemhuge>`` + + Select mempool allocation mode: + + * native: create and populate mempool using native DPDK memory + * anon: create mempool using native DPDK memory, but populate using + anonymous memory + * xmem: create and populate mempool using externally and anonymously + allocated area + * xmemhuge: create and populate mempool using externally and anonymously + allocated hugepage area + +* ``--noisy-tx-sw-buffer-size`` + + Set the number of maximum elements of the FIFO queue to be created + for buffering packets. Only available with the noisy forwarding mode. + The default value is 0. + +* ``--noisy-tx-sw-buffer-flushtime=N`` + + Set the time before packets in the FIFO queue is flushed. + Only available with the noisy forwarding mode. The default value is 0. + +* ``--noisy-lkup-memory=N`` + + Set the size of the noisy neighbour simulation memory buffer in MB to N. + Only available with the noisy forwarding mode. The default value is 0. + + +* ``--noisy-lkup-num-reads=N`` + + Set the number of reads to be done in noisy neighbour simulation memory buffer to N. + Only available with the noisy forwarding mode. The default value is 0. + +* ``--noisy-lkup-num-writes=N`` + + Set the number of writes to be done in noisy neighbour simulation memory buffer to N. + Only available with the noisy forwarding mode. The default value is 0. + +* ``--noisy-lkup-num-reads-writes=N`` + + Set the number of r/w accesses to be done in noisy neighbour simulation memory buffer to N. + Only available with the noisy forwarding mode. The default value is 0. diff --git a/doc/guides/testpmd_app_ug/testpmd_funcs.rst b/doc/guides/testpmd_app_ug/testpmd_funcs.rst index dde205a2..e23079b6 100644 --- a/doc/guides/testpmd_app_ug/testpmd_funcs.rst +++ b/doc/guides/testpmd_app_ug/testpmd_funcs.rst @@ -159,12 +159,14 @@ show port Display information for a given port or all ports:: - testpmd> show port (info|stats|xstats|fdir|stat_qmap|dcb_tc|cap) (port_id|all) + testpmd> show port (info|summary|stats|xstats|fdir|stat_qmap|dcb_tc|cap) (port_id|all) The available information categories are: * ``info``: General port information such as MAC address. +* ``summary``: Brief port summary such as Device Name, Driver Name etc. + * ``stats``: RX/TX statistics. * ``xstats``: RX/TX extended NIC statistics. @@ -231,7 +233,7 @@ show port rss-hash Display the RSS hash functions and RSS hash key of a port:: - testpmd> show port (port_id) rss-hash ipv4|ipv4-frag|ipv4-tcp|ipv4-udp|ipv4-sctp|ipv4-other|ipv6|ipv6-frag|ipv6-tcp|ipv6-udp|ipv6-sctp|ipv6-other|l2-payload|ipv6-ex|ipv6-tcp-ex|ipv6-udp-ex [key] + testpmd> show port (port_id) rss-hash [key] clear port ~~~~~~~~~~ @@ -289,7 +291,7 @@ set fwd Set the packet forwarding mode:: testpmd> set fwd (io|mac|macswap|flowgen| \ - rxonly|txonly|csum|icmpecho) (""|retry) + rxonly|txonly|csum|icmpecho|noisy) (""|retry) ``retry`` can be specified for forwarding engines except ``rx_only``. @@ -323,6 +325,10 @@ The available information categories are: * ``softnic``: Demonstrates the softnic forwarding operation. In this mode, packet forwarding is similar to I/O mode except for the fact that packets are loopback to the softnic ports only. Therefore, portmask parameter should be set to softnic port only. The various software based custom NIC pipelines specified through the softnic firmware (DPDK packet framework script) can be tested in this mode. Furthermore, it allows to build 5-level hierarchical QoS scheduler as a default option that can be enabled through CLI once testpmd application is initialised. The user can modify the default scheduler hierarchy or can specify the new QoS Scheduler hierarchy through CLI. Requires ``CONFIG_RTE_LIBRTE_PMD_SOFTNIC=y``. +* ``noisy``: Noisy neighbour simulation. + Simulate more realistic behavior of a guest machine engaged in receiving + and sending packets performing Virtual Network Function (VNF). + Example:: testpmd> set fwd rxonly @@ -417,6 +423,12 @@ List port level and all queue level Tx offloading configuration:: testpmd> show port (port_id) tx_offload configuration +show tx metadata setting +~~~~~~~~~~~~~~~~~~~~~~~~ + +Show Tx metadata value set for a specific port:: + + testpmd> show port (port_id) tx_metadata Configuration Functions ----------------------- @@ -443,7 +455,12 @@ Set the debug verbosity level:: testpmd> set verbose (level) -Currently the only available levels are 0 (silent except for error) and 1 (fully verbose). +Available levels are as following: + +* ``0`` silent except for error. +* ``1`` fully verbose except for Tx packets. +* ``2`` fully verbose except for Rx packets. +* ``> 2`` fully verbose. set log ~~~~~~~ @@ -592,6 +609,17 @@ For example, to change the port forwarding: RX P=1/Q=0 (socket 0) -> TX P=3/Q=0 (socket 0) peer=02:00:00:00:00:03 RX P=3/Q=0 (socket 0) -> TX P=1/Q=0 (socket 0) peer=02:00:00:00:00:02 +set port setup on +~~~~~~~~~~~~~~~~~ + +Select how to retrieve new ports created after "port attach" command:: + + testpmd> set port setup on (iterator|event) + +For each new port, a setup is done. +It will find the probed ports via RTE_ETH_FOREACH_MATCHING_DEV loop +in iterator mode, or via RTE_ETH_EVENT_NEW in event mode. + set tx loopback ~~~~~~~~~~~~~~~ @@ -857,7 +885,7 @@ csum set Select hardware or software calculation of the checksum when transmitting a packet using the ``csum`` forwarding engine:: - testpmd> csum set (ip|udp|tcp|sctp|outer-ip) (hw|sw) (port_id) + testpmd> csum set (ip|udp|tcp|sctp|outer-ip|outer-udp) (hw|sw) (port_id) Where: @@ -867,6 +895,10 @@ Where: as a tunnel packet by the forwarding engine (vxlan, gre and ipip are supported). See also the ``csum parse-tunnel`` command. +* ``outer-udp`` relates to the outer UDP layer in the case where the packet is recognized + as a tunnel packet by the forwarding engine (vxlan, vxlan-gpe are + supported). See also the ``csum parse-tunnel`` command. + .. note:: Check the NIC Datasheet for hardware limits. @@ -940,7 +972,7 @@ Consider a packet in packet like the following:: * If parse-tunnel is enabled, the ``ip|udp|tcp|sctp`` parameters of ``csum set`` command relate to the inner headers (here ``ipv4_in`` and ``tcp_in``), and the - ``outer-ip parameter`` relates to the outer headers (here ``ipv4_out``). + ``outer-ip|outer-udp`` parameter relates to the outer headers (here ``ipv4_out`` and ``udp_out``). * If parse-tunnel is disabled, the ``ip|udp|tcp|sctp`` parameters of ``csum set`` command relate to the outer headers, here ``ipv4_out`` and ``udp_out``. @@ -1517,7 +1549,8 @@ Enable or disable a per port Tx offloading on all Tx queues of a port:: sctp_cksum, tcp_tso, udp_tso, outer_ipv4_cksum, qinq_insert, vxlan_tnl_tso, gre_tnl_tso, ipip_tnl_tso, geneve_tnl_tso, macsec_insert, - mt_lockfree, multi_segs, mbuf_fast_free, security + mt_lockfree, multi_segs, mbuf_fast_free, security, + match_metadata This command should be run when the port is stopped, or else it will fail. @@ -1570,6 +1603,92 @@ flow rule using the action nvgre_encap will use the last configuration set. To have a different encapsulation header, one of those commands must be called before the flow rule creation. +Config L2 Encap +~~~~~~~~~~~~~~~ + +Configure the l2 to be used when encapsulating a packet with L2:: + + set l2_encap ip-version (ipv4|ipv6) eth-src (eth-src) eth-dst (eth-dst) + set l2_encap-with-vlan ip-version (ipv4|ipv6) vlan-tci (vlan-tci) \ + eth-src (eth-src) eth-dst (eth-dst) + +Those commands will set an internal configuration inside testpmd, any following +flow rule using the action l2_encap will use the last configuration set. +To have a different encapsulation header, one of those commands must be called +before the flow rule creation. + +Config L2 Decap +~~~~~~~~~~~~~~~ + +Configure the l2 to be removed when decapsulating a packet with L2:: + + set l2_decap ip-version (ipv4|ipv6) + set l2_decap-with-vlan ip-version (ipv4|ipv6) + +Those commands will set an internal configuration inside testpmd, any following +flow rule using the action l2_decap will use the last configuration set. +To have a different encapsulation header, one of those commands must be called +before the flow rule creation. + +Config MPLSoGRE Encap outer layers +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Configure the outer layer to encapsulate a packet inside a MPLSoGRE tunnel:: + + set mplsogre_encap ip-version (ipv4|ipv6) label (label) \ + ip-src (ip-src) ip-dst (ip-dst) eth-src (eth-src) eth-dst (eth-dst) + set mplsogre_encap-with-vlan ip-version (ipv4|ipv6) label (label) \ + ip-src (ip-src) ip-dst (ip-dst) vlan-tci (vlan-tci) \ + eth-src (eth-src) eth-dst (eth-dst) + +Those command will set an internal configuration inside testpmd, any following +flow rule using the action mplsogre_encap will use the last configuration set. +To have a different encapsulation header, one of those commands must be called +before the flow rule creation. + +Config MPLSoGRE Decap outer layers +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Configure the outer layer to decapsulate MPLSoGRE packet:: + + set mplsogre_decap ip-version (ipv4|ipv6) + set mplsogre_decap-with-vlan ip-version (ipv4|ipv6) + +Those command will set an internal configuration inside testpmd, any following +flow rule using the action mplsogre_decap will use the last configuration set. +To have a different decapsulation header, one of those commands must be called +before the flow rule creation. + +Config MPLSoUDP Encap outer layers +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Configure the outer layer to encapsulate a packet inside a MPLSoUDP tunnel:: + + set mplsoudp_encap ip-version (ipv4|ipv6) label (label) udp-src (udp-src) \ + udp-dst (udp-dst) ip-src (ip-src) ip-dst (ip-dst) \ + eth-src (eth-src) eth-dst (eth-dst) + set mplsoudp_encap-with-vlan ip-version (ipv4|ipv6) label (label) \ + udp-src (udp-src) udp-dst (udp-dst) ip-src (ip-src) ip-dst (ip-dst) \ + vlan-tci (vlan-tci) eth-src (eth-src) eth-dst (eth-dst) + +Those command will set an internal configuration inside testpmd, any following +flow rule using the action mplsoudp_encap will use the last configuration set. +To have a different encapsulation header, one of those commands must be called +before the flow rule creation. + +Config MPLSoUDP Decap outer layers +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Configure the outer layer to decapsulate MPLSoUDP packet:: + + set mplsoudp_decap ip-version (ipv4|ipv6) + set mplsoudp_decap-with-vlan ip-version (ipv4|ipv6) + +Those command will set an internal configuration inside testpmd, any following +flow rule using the action mplsoudp_decap will use the last configuration set. +To have a different decapsulation header, one of those commands must be called +before the flow rule creation. + Port Functions -------------- @@ -1765,6 +1884,13 @@ Start/stop a rx/tx queue on a specific port:: testpmd> port (port_id) (rxq|txq) (queue_id) (start|stop) +port config - queue deferred start +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Switch on/off deferred start of a specific port queue:: + + testpmd> port (port_id) (rxq|txq) (queue_id) deferred_start (on|off) + port setup queue ~~~~~~~~~~~~~~~~~~~~~ @@ -2006,6 +2132,14 @@ port config udp_tunnel_port Add/remove UDP tunnel port for VXLAN/GENEVE tunneling protocols:: testpmd> port config (port_id) udp_tunnel_port add|rm vxlan|geneve (udp_port) +port config tx_metadata +~~~~~~~~~~~~~~~~~~~~~~~ + +Set Tx metadata value per port. +testpmd will add this value to any Tx packet sent from this port:: + + testpmd> port config (port_id) tx_metadata (value) + Link Bonding Functions ---------------------- @@ -2656,6 +2790,63 @@ where: call failure. On the other hand, hierarchy is preserved when this parameter is equal to zero. +Set port traffic management mark VLAN dei +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Enables/Disables the traffic management marking on the port for VLAN packets:: + + testpmd> set port tm mark vlan_dei <port_id> <green> <yellow> <red> + +where: + +* ``port_id``: The port which on which VLAN packets marked as ``green`` or + ``yellow`` or ``red`` will have dei bit enabled + +* ``green`` enable 1, disable 0 marking for dei bit of VLAN packets marked as green + +* ``yellow`` enable 1, disable 0 marking for dei bit of VLAN packets marked as yellow + +* ``red`` enable 1, disable 0 marking for dei bit of VLAN packets marked as red + +Set port traffic management mark IP dscp +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Enables/Disables the traffic management marking on the port for IP dscp packets:: + + testpmd> set port tm mark ip_dscp <port_id> <green> <yellow> <red> + +where: + +* ``port_id``: The port which on which IP packets marked as ``green`` or + ``yellow`` or ``red`` will have IP dscp bits updated + +* ``green`` enable 1, disable 0 marking IP dscp to low drop precedence for green packets + +* ``yellow`` enable 1, disable 0 marking IP dscp to medium drop precedence for yellow packets + +* ``red`` enable 1, disable 0 marking IP dscp to high drop precedence for red packets + +Set port traffic management mark IP ecn +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Enables/Disables the traffic management marking on the port for IP ecn packets:: + + testpmd> set port tm mark ip_ecn <port_id> <green> <yellow> <red> + +where: + +* ``port_id``: The port which on which IP packets marked as ``green`` or + ``yellow`` or ``red`` will have IP ecn bits updated + +* ``green`` enable 1, disable 0 marking IP ecn for green marked packets with ecn of 2'b01 or 2'b10 + to ecn of 2'b11 when IP is caring TCP or SCTP + +* ``yellow`` enable 1, disable 0 marking IP ecn for yellow marked packets with ecn of 2'b01 or 2'b10 + to ecn of 2'b11 when IP is caring TCP or SCTP + +* ``red`` enable 1, disable 0 marking IP ecn for yellow marked packets with ecn of 2'b01 or 2'b10 + to ecn of 2'b11 when IP is caring TCP or SCTP + Set port traffic management default hierarchy (softnic forwarding mode) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -3516,6 +3707,10 @@ This section lists supported pattern items and their attributes, if any. - ``tla {MAC-48}``: target Ethernet LLA. +- ``meta``: match application specific metadata. + + - ``data {unsigned}``: metadata value. + Actions list ^^^^^^^^^^^^ @@ -3697,6 +3892,68 @@ This section lists supported actions and their attributes, if any. - ``nvgre_decap``: Performs a decapsulation action by stripping all headers of the NVGRE tunnel network overlay from the matched flow. +- ``l2_encap``: Performs a L2 encapsulation, L2 configuration + is done through `Config L2 Encap`_. + +- ``l2_decap``: Performs a L2 decapsulation, L2 configuration + is done through `Config L2 Decap`_. + +- ``mplsogre_encap``: Performs a MPLSoGRE encapsulation, outer layer + configuration is done through `Config MPLSoGRE Encap outer layers`_. + +- ``mplsogre_decap``: Performs a MPLSoGRE decapsulation, outer layer + configuration is done through `Config MPLSoGRE Decap outer layers`_. + +- ``mplsoudp_encap``: Performs a MPLSoUDP encapsulation, outer layer + configuration is done through `Config MPLSoUDP Encap outer layers`_. + +- ``mplsoudp_decap``: Performs a MPLSoUDP decapsulation, outer layer + configuration is done through `Config MPLSoUDP Decap outer layers`_. + +- ``set_ipv4_src``: Set a new IPv4 source address in the outermost IPv4 header. + + - ``ipv4_addr``: New IPv4 source address. + +- ``set_ipv4_dst``: Set a new IPv4 destination address in the outermost IPv4 + header. + + - ``ipv4_addr``: New IPv4 destination address. + +- ``set_ipv6_src``: Set a new IPv6 source address in the outermost IPv6 header. + + - ``ipv6_addr``: New IPv6 source address. + +- ``set_ipv6_dst``: Set a new IPv6 destination address in the outermost IPv6 + header. + + - ``ipv6_addr``: New IPv6 destination address. + +- ``of_set_tp_src``: Set a new source port number in the outermost TCP/UDP + header. + + - ``port``: New TCP/UDP source port number. + +- ``of_set_tp_dst``: Set a new destination port number in the outermost TCP/UDP + header. + + - ``port``: New TCP/UDP destination port number. + +- ``mac_swap``: Swap the source and destination MAC addresses in the outermost + Ethernet header. + +- ``dec_ttl``: Performs a decrease TTL value action + +- ``set_ttl``: Set TTL value with specificed value + - ``ttl_value {unsigned}``: The new TTL value to be set + +- ``set_mac_src``: set source MAC address + + - ``mac_addr {MAC-48}``: new source MAC address + +- ``set_mac_dst``: set destination MAC address + + - ``mac_addr {MAC-48}``: new destination MAC address + Destroying flow rules ~~~~~~~~~~~~~~~~~~~~~ @@ -4025,6 +4282,180 @@ IPv6 NVGRE outer header:: testpmd> flow create 0 ingress pattern end actions nvgre_encap / queue index 0 / end +Sample L2 encapsulation rule +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +L2 encapsulation has default value pre-configured in testpmd +source code, those can be changed by using the following commands + +L2 header:: + + testpmd> set l2_encap ip-version ipv4 + eth-src 11:11:11:11:11:11 eth-dst 22:22:22:22:22:22 + testpmd> flow create 0 ingress pattern eth / ipv4 / udp / mpls / end actions + mplsoudp_decap / l2_encap / end + +L2 with VXLAN header:: + + testpmd> set l2_encap-with-vlan ip-version ipv4 vlan-tci 34 + eth-src 11:11:11:11:11:11 eth-dst 22:22:22:22:22:22 + testpmd> flow create 0 ingress pattern eth / ipv4 / udp / mpls / end actions + mplsoudp_decap / l2_encap / end + +Sample L2 decapsulation rule +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +L2 decapsulation has default value pre-configured in testpmd +source code, those can be changed by using the following commands + +L2 header:: + + testpmd> set l2_decap + testpmd> flow create 0 egress pattern eth / end actions l2_decap / mplsoudp_encap / + queue index 0 / end + +L2 with VXLAN header:: + + testpmd> set l2_encap-with-vlan + testpmd> flow create 0 egress pattern eth / end actions l2_encap / mplsoudp_encap / + queue index 0 / end + +Sample MPLSoGRE encapsulation rule +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +MPLSoGRE encapsulation outer layer has default value pre-configured in testpmd +source code, those can be changed by using the following commands + +IPv4 MPLSoGRE outer header:: + + testpmd> set mplsogre_encap ip-version ipv4 label 4 + ip-src 127.0.0.1 ip-dst 128.0.0.1 eth-src 11:11:11:11:11:11 + eth-dst 22:22:22:22:22:22 + testpmd> flow create 0 egress pattern eth / end actions l2_decap / + mplsogre_encap / end + +IPv4 MPLSoGRE with VLAN outer header:: + + testpmd> set mplsogre_encap-with-vlan ip-version ipv4 label 4 + ip-src 127.0.0.1 ip-dst 128.0.0.1 vlan-tci 34 + eth-src 11:11:11:11:11:11 eth-dst 22:22:22:22:22:22 + testpmd> flow create 0 egress pattern eth / end actions l2_decap / + mplsogre_encap / end + +IPv6 MPLSoGRE outer header:: + + testpmd> set mplsogre_encap ip-version ipv6 mask 4 + ip-src ::1 ip-dst ::2222 eth-src 11:11:11:11:11:11 + eth-dst 22:22:22:22:22:22 + testpmd> flow create 0 egress pattern eth / end actions l2_decap / + mplsogre_encap / end + +IPv6 MPLSoGRE with VLAN outer header:: + + testpmd> set mplsogre_encap-with-vlan ip-version ipv6 mask 4 + ip-src ::1 ip-dst ::2222 vlan-tci 34 + eth-src 11:11:11:11:11:11 eth-dst 22:22:22:22:22:22 + testpmd> flow create 0 egress pattern eth / end actions l2_decap / + mplsogre_encap / end + +Sample MPLSoGRE decapsulation rule +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +MPLSoGRE decapsulation outer layer has default value pre-configured in testpmd +source code, those can be changed by using the following commands + +IPv4 MPLSoGRE outer header:: + + testpmd> set mplsogre_decap ip-version ipv4 + testpmd> flow create 0 ingress pattern eth / ipv4 / gre / mpls / end actions + mplsogre_decap / l2_encap / end + +IPv4 MPLSoGRE with VLAN outer header:: + + testpmd> set mplsogre_decap-with-vlan ip-version ipv4 + testpmd> flow create 0 ingress pattern eth / vlan / ipv4 / gre / mpls / end + actions mplsogre_decap / l2_encap / end + +IPv6 MPLSoGRE outer header:: + + testpmd> set mplsogre_decap ip-version ipv6 + testpmd> flow create 0 ingress pattern eth / ipv6 / gre / mpls / end + actions mplsogre_decap / l2_encap / end + +IPv6 MPLSoGRE with VLAN outer header:: + + testpmd> set mplsogre_decap-with-vlan ip-version ipv6 + testpmd> flow create 0 ingress pattern eth / vlan / ipv6 / gre / mpls / end + actions mplsogre_decap / l2_encap / end + +Sample MPLSoUDP encapsulation rule +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +MPLSoUDP encapsulation outer layer has default value pre-configured in testpmd +source code, those can be changed by using the following commands + +IPv4 MPLSoUDP outer header:: + + testpmd> set mplsoudp_encap ip-version ipv4 label 4 udp-src 5 udp-dst 10 + ip-src 127.0.0.1 ip-dst 128.0.0.1 eth-src 11:11:11:11:11:11 + eth-dst 22:22:22:22:22:22 + testpmd> flow create 0 egress pattern eth / end actions l2_decap / + mplsoudp_encap / end + +IPv4 MPLSoUDP with VLAN outer header:: + + testpmd> set mplsoudp_encap-with-vlan ip-version ipv4 label 4 udp-src 5 + udp-dst 10 ip-src 127.0.0.1 ip-dst 128.0.0.1 vlan-tci 34 + eth-src 11:11:11:11:11:11 eth-dst 22:22:22:22:22:22 + testpmd> flow create 0 egress pattern eth / end actions l2_decap / + mplsoudp_encap / end + +IPv6 MPLSoUDP outer header:: + + testpmd> set mplsoudp_encap ip-version ipv6 mask 4 udp-src 5 udp-dst 10 + ip-src ::1 ip-dst ::2222 eth-src 11:11:11:11:11:11 + eth-dst 22:22:22:22:22:22 + testpmd> flow create 0 egress pattern eth / end actions l2_decap / + mplsoudp_encap / end + +IPv6 MPLSoUDP with VLAN outer header:: + + testpmd> set mplsoudp_encap-with-vlan ip-version ipv6 mask 4 udp-src 5 + udp-dst 10 ip-src ::1 ip-dst ::2222 vlan-tci 34 + eth-src 11:11:11:11:11:11 eth-dst 22:22:22:22:22:22 + testpmd> flow create 0 egress pattern eth / end actions l2_decap / + mplsoudp_encap / end + +Sample MPLSoUDP decapsulation rule +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +MPLSoUDP decapsulation outer layer has default value pre-configured in testpmd +source code, those can be changed by using the following commands + +IPv4 MPLSoUDP outer header:: + + testpmd> set mplsoudp_decap ip-version ipv4 + testpmd> flow create 0 ingress pattern eth / ipv4 / udp / mpls / end actions + mplsoudp_decap / l2_encap / end + +IPv4 MPLSoUDP with VLAN outer header:: + + testpmd> set mplsoudp_decap-with-vlan ip-version ipv4 + testpmd> flow create 0 ingress pattern eth / vlan / ipv4 / udp / mpls / end + actions mplsoudp_decap / l2_encap / end + +IPv6 MPLSoUDP outer header:: + + testpmd> set mplsoudp_decap ip-version ipv6 + testpmd> flow create 0 ingress pattern eth / ipv6 / udp / mpls / end + actions mplsoudp_decap / l2_encap / end + +IPv6 MPLSoUDP with VLAN outer header:: + + testpmd> set mplsoudp_decap-with-vlan ip-version ipv6 + testpmd> flow create 0 ingress pattern eth / vlan / ipv6 / udp / mpls / end + actions mplsoudp_decap / l2_encap / end + BPF Functions -------------- diff --git a/doc/guides/tools/img/eventdev_pipeline_atq_test_generic.svg b/doc/guides/tools/img/eventdev_pipeline_atq_test_generic.svg index e3336798..707b9b56 100644 --- a/doc/guides/tools/img/eventdev_pipeline_atq_test_generic.svg +++ b/doc/guides/tools/img/eventdev_pipeline_atq_test_generic.svg @@ -20,7 +20,7 @@ height="288.34286" id="svg3868" version="1.1" - inkscape:version="0.92.2 (5c3e80d, 2017-08-06)" + inkscape:version="0.92.2 2405546, 2018-03-11" sodipodi:docname="eventdev_pipeline_atq_test_generic.svg" sodipodi:version="0.32" inkscape:output_extension="org.inkscape.output.svg.inkscape" @@ -43,22 +43,6 @@ id="path39725" /> </marker> <marker - inkscape:stockid="TriangleOutM" - orient="auto" - refY="0" - refX="0" - id="marker35935" - style="overflow:visible" - inkscape:isstock="true" - inkscape:collect="always"> - <path - id="path35933" - d="M 5.77,0 -2.88,5 V -5 Z" - style="fill:#ac14ff;fill-opacity:1;fill-rule:evenodd;stroke:#ac14ff;stroke-width:1.00000003pt;stroke-opacity:1" - transform="scale(0.4)" - inkscape:connector-curvature="0" /> - </marker> - <marker inkscape:isstock="true" style="overflow:visible" id="marker32613" @@ -1430,9 +1414,9 @@ x2="677.85718" y2="244.50504" gradientUnits="userSpaceOnUse" - gradientTransform="matrix(0.78263355,0,0,0.98605918,90.06838,5.0013749)" /> + gradientTransform="matrix(0.84881476,0,0,0.98593266,86.966576,5.0323108)" /> <linearGradient - gradientTransform="matrix(0.78674479,0,0,1.0000825,87.83543,1.2279738)" + gradientTransform="matrix(0.85327366,0,0,0.99995418,84.544803,1.2593939)" inkscape:collect="always" xlink:href="#linearGradient6391" id="linearGradient2965" @@ -1865,36 +1849,6 @@ effect="spiro" id="path-effect14461-7-5-6" is_visible="true" /> - <linearGradient - inkscape:collect="always" - xlink:href="#linearGradient3993" - id="linearGradient3995-5" - x1="155.21329" - y1="231.61366" - x2="207.95523" - y2="231.61366" - gradientUnits="userSpaceOnUse" - gradientTransform="translate(454.68566,-41.755492)" /> - <linearGradient - inkscape:collect="always" - xlink:href="#linearGradient3993" - id="linearGradient3995-5-6" - x1="155.21329" - y1="231.61366" - x2="207.95523" - y2="231.61366" - gradientUnits="userSpaceOnUse" - gradientTransform="translate(373.71198,205.50594)" /> - <linearGradient - inkscape:collect="always" - xlink:href="#linearGradient3993" - id="linearGradient3995-5-6-4" - x1="155.21329" - y1="231.61366" - x2="207.95523" - y2="231.61366" - gradientUnits="userSpaceOnUse" - gradientTransform="translate(454.58517,69.679557)" /> <inkscape:path-effect effect="bspline" id="path-effect2658-8" @@ -2048,16 +2002,6 @@ apply_no_weight="true" apply_with_weight="true" only_selected="false" /> - <linearGradient - inkscape:collect="always" - xlink:href="#linearGradient3438" - id="linearGradient16362" - gradientUnits="userSpaceOnUse" - gradientTransform="translate(2.283166,-2.283166)" - x1="534.06958" - y1="163.49922" - x2="580.73291" - y2="163.49922" /> <marker inkscape:stockid="Arrow1Mend" orient="auto" @@ -2293,25 +2237,80 @@ apply_no_weight="true" apply_with_weight="true" only_selected="false" /> + <inkscape:path-effect + effect="bspline" + id="path-effect5228-5-1-6-2-9-4-6-1-2" + is_visible="true" + weight="33.333333" + steps="2" + helper_size="0" + apply_no_weight="true" + apply_with_weight="true" + only_selected="false" /> + <inkscape:path-effect + effect="bspline" + id="path-effect5228-5-1-6-2-9-4-6-1-2-9" + is_visible="true" + weight="33.333333" + steps="2" + helper_size="0" + apply_no_weight="true" + apply_with_weight="true" + only_selected="false" /> + <inkscape:path-effect + effect="bspline" + id="path-effect5228-5-1-6-2-9-4-6-1-2-9-4" + is_visible="true" + weight="33.333333" + steps="2" + helper_size="0" + apply_no_weight="true" + apply_with_weight="true" + only_selected="false" /> + <marker + inkscape:isstock="true" + style="overflow:visible" + id="marker32613-8-5" + refX="0" + refY="0" + orient="auto" + inkscape:stockid="TriangleOutM"> + <path + inkscape:connector-curvature="0" + transform="scale(0.4)" + style="fill:#ac14ff;fill-opacity:1;fill-rule:evenodd;stroke:#ac14ff;stroke-width:1.00000003pt;stroke-opacity:1" + d="M 5.77,0 -2.88,5 V -5 Z" + id="path32611-8-0" /> + </marker> + <inkscape:path-effect + effect="bspline" + id="path-effect5228-5-1-6-2-9-4-6-4-4" + is_visible="true" + weight="33.333333" + steps="2" + helper_size="0" + apply_no_weight="true" + apply_with_weight="true" + only_selected="false" /> <marker inkscape:stockid="TriangleOutM" orient="auto" refY="0" refX="0" - id="marker35935-1" + id="TriangleOutM-5-2-3" style="overflow:visible" inkscape:isstock="true" inkscape:collect="always"> <path - id="path35933-49" + inkscape:connector-curvature="0" + id="path2123-3-9-20" d="M 5.77,0 -2.88,5 V -5 Z" - style="fill:#ac14ff;fill-opacity:1;fill-rule:evenodd;stroke:#ac14ff;stroke-width:1.00000003pt;stroke-opacity:1" - transform="scale(0.4)" - inkscape:connector-curvature="0" /> + style="fill:#f78202;fill-opacity:1;fill-rule:evenodd;stroke:#f78202;stroke-width:1.00000003pt;stroke-opacity:1" + transform="scale(0.4)" /> </marker> <inkscape:path-effect effect="bspline" - id="path-effect5228-5-1-6-2-9-4-6-1-2" + id="path-effect5228-5-1-61" is_visible="true" weight="33.333333" steps="2" @@ -2324,20 +2323,92 @@ orient="auto" refY="0" refX="0" - id="marker35935-1-6" + id="TriangleOutM-5-2-3-0" style="overflow:visible" inkscape:isstock="true" inkscape:collect="always"> <path - id="path35933-49-8" + inkscape:connector-curvature="0" + id="path2123-3-9-20-6" d="M 5.77,0 -2.88,5 V -5 Z" - style="fill:#ac14ff;fill-opacity:1;fill-rule:evenodd;stroke:#ac14ff;stroke-width:1.00000003pt;stroke-opacity:1" + style="fill:#f78202;fill-opacity:1;fill-rule:evenodd;stroke:#f78202;stroke-width:1.00000003pt;stroke-opacity:1" + transform="scale(0.4)" /> + </marker> + <inkscape:path-effect + effect="bspline" + id="path-effect5228-5-1-61-1" + is_visible="true" + weight="33.333333" + steps="2" + helper_size="0" + apply_no_weight="true" + apply_with_weight="true" + only_selected="false" /> + <marker + inkscape:stockid="TriangleOutM" + orient="auto" + refY="0" + refX="0" + id="TriangleOutM-5-2-3-9" + style="overflow:visible" + inkscape:isstock="true" + inkscape:collect="always"> + <path + inkscape:connector-curvature="0" + id="path2123-3-9-20-4" + d="M 5.77,0 -2.88,5 V -5 Z" + style="fill:#f78202;fill-opacity:1;fill-rule:evenodd;stroke:#f78202;stroke-width:1.00000003pt;stroke-opacity:1" + transform="scale(0.4)" /> + </marker> + <inkscape:path-effect + effect="bspline" + id="path-effect5228-5-1-61-9" + is_visible="true" + weight="33.333333" + steps="2" + helper_size="0" + apply_no_weight="true" + apply_with_weight="true" + only_selected="false" /> + <linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient3995-5" + x1="155.21329" + y1="231.61366" + x2="207.95523" + y2="231.61366" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(454.68566,-41.755492)" /> + <linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient3995-8" + x1="155.21329" + y1="231.61366" + x2="207.95523" + y2="231.61366" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.3938205,0,0,0.9944124,282.08991,-43.80364)" /> + <marker + inkscape:stockid="TriangleOutM" + orient="auto" + refY="0" + refX="0" + id="marker35935-1-6-5-1-0" + style="overflow:visible" + inkscape:isstock="true" + inkscape:collect="always"> + <path + id="path35933-49-8-6-2-3" + d="M 5.77,0 -2.88,5 V -5 Z" + style="fill:#ac14db;fill-opacity:1;fill-rule:evenodd;stroke:#ac14ff;stroke-width:1.00000003pt;stroke-opacity:1" transform="scale(0.4)" inkscape:connector-curvature="0" /> </marker> <inkscape:path-effect effect="bspline" - id="path-effect5228-5-1-6-2-9-4-6-1-2-9" + id="path-effect5228-5-1-6-2-9-4-6-1-2-9-2-7-6" is_visible="true" weight="33.333333" steps="2" @@ -2350,20 +2421,20 @@ orient="auto" refY="0" refX="0" - id="marker35935-1-6-6" + id="marker35935-1-6-5-1-0-0" style="overflow:visible" inkscape:isstock="true" inkscape:collect="always"> <path - id="path35933-49-8-6" + id="path35933-49-8-6-2-3-6" d="M 5.77,0 -2.88,5 V -5 Z" - style="fill:#ac14ff;fill-opacity:1;fill-rule:evenodd;stroke:#ac14ff;stroke-width:1.00000003pt;stroke-opacity:1" + style="fill:#ac14db;fill-opacity:1;fill-rule:evenodd;stroke:#ac14ff;stroke-width:1.00000003pt;stroke-opacity:1" transform="scale(0.4)" inkscape:connector-curvature="0" /> </marker> <inkscape:path-effect effect="bspline" - id="path-effect5228-5-1-6-2-9-4-6-1-2-9-4" + id="path-effect5228-5-1-6-2-9-4-6-1-2-9-2-7-6-3" is_visible="true" weight="33.333333" steps="2" @@ -2371,24 +2442,45 @@ apply_no_weight="true" apply_with_weight="true" only_selected="false" /> + <linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient3995-5-6" + x1="155.21329" + y1="231.61366" + x2="207.95523" + y2="231.61366" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(373.71198,205.50594)" /> + <linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient3995-5-6-4" + x1="155.21329" + y1="231.61366" + x2="207.95523" + y2="231.61366" + gradientUnits="userSpaceOnUse" + gradientTransform="translate(454.58517,69.679557)" /> <marker - inkscape:isstock="true" - style="overflow:visible" - id="marker32613-8-5" - refX="0" - refY="0" + inkscape:stockid="TriangleOutM" orient="auto" - inkscape:stockid="TriangleOutM"> + refY="0" + refX="0" + id="marker35935-1-6-5-1-0-06" + style="overflow:visible" + inkscape:isstock="true" + inkscape:collect="always"> <path - inkscape:connector-curvature="0" - transform="scale(0.4)" - style="fill:#ac14ff;fill-opacity:1;fill-rule:evenodd;stroke:#ac14ff;stroke-width:1.00000003pt;stroke-opacity:1" + id="path35933-49-8-6-2-3-1" d="M 5.77,0 -2.88,5 V -5 Z" - id="path32611-8-0" /> + style="fill:#ac14db;fill-opacity:1;fill-rule:evenodd;stroke:#ac14ff;stroke-width:1.00000003pt;stroke-opacity:1" + transform="scale(0.4)" + inkscape:connector-curvature="0" /> </marker> <inkscape:path-effect effect="bspline" - id="path-effect5228-5-1-6-2-9-4-6-4-4" + id="path-effect5228-5-1-6-2-9-4-6-1-2-9-2-7-6-5" is_visible="true" weight="33.333333" steps="2" @@ -2399,32 +2491,52 @@ <linearGradient inkscape:collect="always" xlink:href="#linearGradient3993" - id="linearGradient1920-1" - x1="475.00314" - y1="156.97769" - x2="515.13684" - y2="156.97769" + id="linearGradient3995-8-9-9" + x1="155.21329" + y1="231.61366" + x2="207.95523" + y2="231.61366" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.3938205,0,0,0.9944124,282.25651,68.385308)" /> + <linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient3995-8-9" + x1="155.21329" + y1="231.61366" + x2="207.95523" + y2="231.61366" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.3938205,0,0,0.9944124,282.88878,12.631328)" /> + <linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient1760-3" + x1="405.34961" + y1="243.36557" + x2="651.55652" + y2="243.36557" gradientUnits="userSpaceOnUse" - gradientTransform="matrix(0.6515192,0,0,1.0041442,189.20967,67.917365)" /> + gradientTransform="matrix(0.65213006,0,0,0.72134316,230.98899,64.590305)" /> <marker inkscape:stockid="TriangleOutM" orient="auto" refY="0" refX="0" - id="TriangleOutM-5-2-3" + id="marker35935-1-6-5" style="overflow:visible" inkscape:isstock="true" inkscape:collect="always"> <path - inkscape:connector-curvature="0" - id="path2123-3-9-20" + id="path35933-49-8-6" d="M 5.77,0 -2.88,5 V -5 Z" - style="fill:#f78202;fill-opacity:1;fill-rule:evenodd;stroke:#f78202;stroke-width:1.00000003pt;stroke-opacity:1" - transform="scale(0.4)" /> + style="fill:#ac14db;fill-opacity:1;fill-rule:evenodd;stroke:#ac14ff;stroke-width:1.00000003pt;stroke-opacity:1" + transform="scale(0.4)" + inkscape:connector-curvature="0" /> </marker> <inkscape:path-effect effect="bspline" - id="path-effect5228-5-1-61" + id="path-effect5228-5-1-6-2-9-4-6-1-2-9-2" is_visible="true" weight="33.333333" steps="2" @@ -2437,20 +2549,20 @@ orient="auto" refY="0" refX="0" - id="TriangleOutM-5-2-3-0" + id="marker35935-1-6-5-1" style="overflow:visible" inkscape:isstock="true" inkscape:collect="always"> <path - inkscape:connector-curvature="0" - id="path2123-3-9-20-6" + id="path35933-49-8-6-2" d="M 5.77,0 -2.88,5 V -5 Z" - style="fill:#f78202;fill-opacity:1;fill-rule:evenodd;stroke:#f78202;stroke-width:1.00000003pt;stroke-opacity:1" - transform="scale(0.4)" /> + style="fill:#ac14db;fill-opacity:1;fill-rule:evenodd;stroke:#ac14ff;stroke-width:1.00000003pt;stroke-opacity:1" + transform="scale(0.4)" + inkscape:connector-curvature="0" /> </marker> <inkscape:path-effect effect="bspline" - id="path-effect5228-5-1-61-1" + id="path-effect5228-5-1-6-2-9-4-6-1-2-9-2-7" is_visible="true" weight="33.333333" steps="2" @@ -2463,20 +2575,20 @@ orient="auto" refY="0" refX="0" - id="TriangleOutM-5-2-3-9" + id="marker35935-1-6-5-9" style="overflow:visible" inkscape:isstock="true" inkscape:collect="always"> <path - inkscape:connector-curvature="0" - id="path2123-3-9-20-4" + id="path35933-49-8-6-3" d="M 5.77,0 -2.88,5 V -5 Z" - style="fill:#f78202;fill-opacity:1;fill-rule:evenodd;stroke:#f78202;stroke-width:1.00000003pt;stroke-opacity:1" - transform="scale(0.4)" /> + style="fill:#ac14db;fill-opacity:1;fill-rule:evenodd;stroke:#ac14ff;stroke-width:1.00000003pt;stroke-opacity:1" + transform="scale(0.4)" + inkscape:connector-curvature="0" /> </marker> <inkscape:path-effect effect="bspline" - id="path-effect5228-5-1-61-9" + id="path-effect5228-5-1-6-2-9-4-6-1-2-9-2-6" is_visible="true" weight="33.333333" steps="2" @@ -2492,17 +2604,17 @@ borderopacity="1.0" inkscape:pageopacity="0.0" inkscape:pageshadow="2" - inkscape:zoom="1.53467" - inkscape:cx="477.6217" - inkscape:cy="141.14731" + inkscape:zoom="2.200307" + inkscape:cx="336.61535" + inkscape:cy="145.77389" inkscape:document-units="px" inkscape:current-layer="layer1" showgrid="false" - inkscape:window-width="1920" - inkscape:window-height="1046" - inkscape:window-x="1920" - inkscape:window-y="34" - inkscape:window-maximized="1" + inkscape:window-width="1912" + inkscape:window-height="1033" + inkscape:window-x="4" + inkscape:window-y="22" + inkscape:window-maximized="0" fit-margin-top="0.1" fit-margin-left="0.1" fit-margin-right="0.1" @@ -2530,12 +2642,12 @@ transform="translate(-46.542857,-100.33361)" style="display:inline;opacity:1"> <rect - style="fill:url(#linearGradient4519);fill-opacity:1;stroke:url(#linearGradient2965);stroke-width:0.87847757;stroke-opacity:1" + style="fill:url(#linearGradient4519);fill-opacity:1;stroke:url(#linearGradient2965);stroke-width:0.91480815;stroke-opacity:1" id="rect3697" - width="493.61813" - height="283.13986" - x="126.96397" - y="104.52792" + width="535.35956" + height="283.10355" + x="126.98213" + y="104.54609" rx="0" ry="0" /> <text @@ -2706,7 +2818,7 @@ x="199.44385" y="188.49918" id="tspan5223-0-9" - style="font-size:10px;line-height:1.25">port n+2</tspan></text> + style="font-size:10px;line-height:1.25">port n+1</tspan></text> <rect style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:url(#linearGradient1920);stroke-width:1.06814909;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" id="rect3736-8-4" @@ -2777,7 +2889,7 @@ x="199.35846" y="244.55573" id="tspan5223-0-9-0" - style="font-size:10px;line-height:1.25">port n+3</tspan></text> + style="font-size:10px;line-height:1.25">port n+2</tspan></text> <rect style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:url(#linearGradient1920-2);stroke-width:1.06814909;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" id="rect3736-8-4-6" @@ -2882,7 +2994,7 @@ x="242.32845" y="123.36828" id="tspan5223-10" - style="font-size:10px;line-height:1.25">total queues = number of ethernet dev + 1</tspan></text> + style="font-size:10px;line-height:1.25">total queues = 2 * number of ethernet dev </tspan></text> <text xml:space="preserve" style="font-style:normal;font-weight:normal;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none" @@ -2957,9 +3069,109 @@ x="285.26294" y="240.01315" style="stroke-width:0.68894428" /></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:11.59418297px;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.96618187" + x="259.86884" + y="164.78368" + id="text5219-2-3-7-2-1" + transform="scale(0.97663117,1.023928)"><tspan + sodipodi:role="line" + x="259.86884" + y="164.78368" + id="tspan5223-0-6-5-9-5" + style="font-size:8px;line-height:1.25;stroke-width:0.96618187">Event eth</tspan><tspan + sodipodi:role="line" + x="259.86884" + y="174.78368" + style="font-size:8px;line-height:1.25;stroke-width:0.96618187" + id="tspan883-1-9">Rx adptr 0</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:11.59418297px;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.96618187" + x="260.25055" + y="217.84813" + id="text5219-2-3-7-2-1-4" + transform="scale(0.97663117,1.023928)"><tspan + sodipodi:role="line" + x="260.25055" + y="217.84813" + id="tspan5223-0-6-5-9-5-4" + style="font-size:8px;line-height:1.25;stroke-width:0.96618187">Event eth</tspan><tspan + sodipodi:role="line" + x="260.25055" + y="227.84813" + style="font-size:8px;line-height:1.25;stroke-width:0.96618187" + id="tspan883-1-9-4">Rx adptr 1</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:11.59418297px;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.96618187" + x="260.25055" + y="271.71359" + id="text5219-2-3-7-2-1-47" + transform="scale(0.97663117,1.023928)"><tspan + sodipodi:role="line" + x="260.25055" + y="271.71359" + id="tspan5223-0-6-5-9-5-6" + style="font-size:8px;line-height:1.25;stroke-width:0.96618187">Event eth</tspan><tspan + sodipodi:role="line" + x="260.25055" + y="281.71359" + style="font-size:8px;line-height:1.25;stroke-width:0.96618187" + id="tspan883-1-9-3">Rx adptr q</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:9.9315424px;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.82762849" + x="595.27808" + y="136.64076" + id="text5219-2-4-3-3-4-54-8-8" + transform="scale(0.91487885,1.0930409)"><tspan + sodipodi:role="line" + x="595.27808" + y="139.22064" + style="font-size:7.17278051px;line-height:1.25;stroke-width:0.82762849" + id="tspan1265-4-6-7" /></text> + <path + style="display:inline;opacity:1;fill:none;stroke:#f78202;stroke-width:0.89999998;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3.6, 0.9;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#TriangleOutM-5-2-3)" + d="m 356.74765,186.83153 c 15.88009,-0.11696 31.75919,-0.23391 47.6373,-0.35085" + id="path5226-6-2-5" + inkscape:connector-curvature="0" + inkscape:path-effect="#path-effect5228-5-1-61" + inkscape:original-d="m 356.74765,186.83153 c 15.88008,-0.11795 31.75918,-0.2349 47.6373,-0.35085" + sodipodi:nodetypes="cc" /> + <path + style="display:inline;opacity:1;fill:none;stroke:#f78202;stroke-width:0.89999998;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3.6, 0.9;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#TriangleOutM-5-2-3-0)" + d="m 357.05625,242.97941 c 15.74231,0.0176 31.48469,0.0352 47.22712,0.0528" + id="path5226-6-2-5-5" + inkscape:connector-curvature="0" + inkscape:path-effect="#path-effect5228-5-1-61-1" + inkscape:original-d="m 357.05625,242.97941 c 15.74231,0.0166 31.48469,0.0342 47.22712,0.0528" + sodipodi:nodetypes="cc" /> + <path + style="display:inline;opacity:1;fill:none;stroke:#f78202;stroke-width:0.89337438;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3.57349763, 0.89337441;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#TriangleOutM-5-2-3-9)" + d="m 356.67155,297.12049 c 15.97521,0.0733 31.94945,0.14663 47.92273,0.21994" + id="path5226-6-2-5-0" + inkscape:connector-curvature="0" + inkscape:path-effect="#path-effect5228-5-1-61-9" + inkscape:original-d="m 356.67155,297.12049 c 15.97521,0.0723 31.94945,0.14563 47.92273,0.21994" + sodipodi:nodetypes="cc" /> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:9.9315424px;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.82762849" + x="606.06958" + y="346.46628" + id="text5219-2-4-3-3-4-54-8-7" + transform="scale(0.91487885,1.0930409)"><tspan + sodipodi:role="line" + x="606.06958" + y="346.46628" + style="font-size:7.17278051px;line-height:1.25;stroke-width:0.82762849" + id="tspan1265-4-6-2">(Tx Generic)</tspan></text> <g + style="display:inline;opacity:1" id="g20550" - transform="translate(25.709043,-190.70754)"> + transform="translate(69.258261,-194.86398)"> <rect ry="16.293755" rx="11.6051" @@ -2988,8 +3200,9 @@ sodipodi:role="line"> Txq 0</tspan></text> </g> <g + style="display:inline;opacity:1" id="g13899" - transform="translate(-54.904385,-3.0966742)"> + transform="translate(-12.211349,-3.253112)"> <rect ry="16.293755" rx="11.6051" @@ -3018,8 +3231,9 @@ sodipodi:role="line"> Txq 0</tspan></text> </g> <g + style="display:inline;opacity:1" id="g13911" - transform="translate(-54.904385,-1.0966741)"> + transform="translate(-10.498979,-2.682322)"> <rect ry="16.293755" rx="11.6051" @@ -3047,217 +3261,205 @@ x="621.71729" sodipodi:role="line"> Txq 0</tspan></text> </g> - <text - xml:space="preserve" - style="font-style:normal;font-weight:normal;font-size:11.59418297px;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.96618187" - x="259.86884" - y="164.78368" - id="text5219-2-3-7-2-1" - transform="scale(0.97663117,1.023928)"><tspan - sodipodi:role="line" - x="259.86884" - y="164.78368" - id="tspan5223-0-6-5-9-5" - style="font-size:8px;line-height:1.25;stroke-width:0.96618187">Event eth</tspan><tspan - sodipodi:role="line" - x="259.86884" - y="174.78368" - style="font-size:8px;line-height:1.25;stroke-width:0.96618187" - id="tspan883-1-9">Rx adptr 0</tspan></text> - <text - xml:space="preserve" - style="font-style:normal;font-weight:normal;font-size:11.59418297px;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.96618187" - x="260.25055" - y="217.84813" - id="text5219-2-3-7-2-1-4" - transform="scale(0.97663117,1.023928)"><tspan - sodipodi:role="line" - x="260.25055" - y="217.84813" - id="tspan5223-0-6-5-9-5-4" - style="font-size:8px;line-height:1.25;stroke-width:0.96618187">Event eth</tspan><tspan - sodipodi:role="line" - x="260.25055" - y="227.84813" - style="font-size:8px;line-height:1.25;stroke-width:0.96618187" - id="tspan883-1-9-4">Rx adptr 1</tspan></text> - <text - xml:space="preserve" - style="font-style:normal;font-weight:normal;font-size:11.59418297px;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.96618187" - x="260.25055" - y="271.71359" - id="text5219-2-3-7-2-1-47" - transform="scale(0.97663117,1.023928)"><tspan - sodipodi:role="line" - x="260.25055" - y="271.71359" - id="tspan5223-0-6-5-9-5-6" - style="font-size:8px;line-height:1.25;stroke-width:0.96618187">Event eth</tspan><tspan - sodipodi:role="line" - x="260.25055" - y="281.71359" - style="font-size:8px;line-height:1.25;stroke-width:0.96618187" - id="tspan883-1-9-3">Rx adptr q</tspan></text> - <g - id="g16360" - transform="matrix(1.0874414,0,0,0.99912695,-98.49816,-6.4077434)"> - <ellipse - ry="24.258638" - rx="22.831659" - cy="161.21605" - cx="559.68445" - id="path8843" - style="fill:#ffffff;fill-opacity:0.98039216;stroke:url(#linearGradient16362);stroke-opacity:1" /> - <text - transform="scale(0.92048084,1.0863887)" - id="text5219-2-4-3-3-4-5" - y="146.21904" - x="588.44147" - style="font-style:normal;font-weight:normal;font-size:11.04576969px;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.92048085" - xml:space="preserve"><tspan - id="tspan1265-5" - style="font-size:7.97750044px;line-height:1.25;stroke-width:0.92048085" - y="146.21904" - x="588.44147" - sodipodi:role="line">Tx Service</tspan><tspan - style="font-size:7.97750044px;line-height:1.25;stroke-width:0.92048085" - y="152.00201" - x="588.44147" - sodipodi:role="line" - id="tspan39139" /><tspan - style="font-size:7.97750044px;line-height:1.25;stroke-width:0.92048085" - y="156.19092" - x="588.44147" - sodipodi:role="line" - id="tspan39141">port n + 1</tspan></text> - </g> - <path - style="display:inline;opacity:1;fill:#ac14ff;fill-opacity:1;stroke:#ac14ff;stroke-width:0.80699998;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3.22799993, 1.61399996;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker32613)" - d="m 511.70299,212.50867 c -0.1614,-10.49392 -0.32276,-20.98539 -0.48409,-31.47439" - id="path5226-6-2-1-2-4-5-1" - inkscape:connector-curvature="0" - inkscape:path-effect="#path-effect5228-5-1-6-2-9-4-6" - inkscape:original-d="m 511.70299,212.50867 c -0.16039,-10.49394 -0.32175,-20.98541 -0.48409,-31.47439" - sodipodi:nodetypes="cc" /> - <path - style="display:inline;opacity:1;fill:#ac14ff;fill-opacity:1;stroke:#ac14ff;stroke-width:0.80699998;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3.228, 0.807;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker35935)" - d="m 523.50111,175.62989 c 10.13298,2.21215 20.26379,4.42384 30.39241,6.63504" - id="path5226-6-2-1-2-4-5-1-5" - inkscape:connector-curvature="0" - inkscape:path-effect="#path-effect5228-5-1-6-2-9-4-6-1" - inkscape:original-d="m 523.50111,175.62989 c 10.13323,2.21099 20.26404,4.42267 30.39241,6.63504" - sodipodi:nodetypes="cc" /> - <path - style="display:inline;opacity:1;fill:#ac14ff;fill-opacity:1;stroke:#ac14ff;stroke-width:0.80699998;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3.228, 0.807;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker35935-5)" - d="m 523.50111,175.62989 c 9.91161,22.53065 19.82206,45.05865 29.73129,67.58389" - id="path5226-6-2-1-2-4-5-1-5-6" - inkscape:connector-curvature="0" - inkscape:path-effect="#path-effect5228-5-1-6-2-9-4-6-1-7" - inkscape:original-d="m 523.50111,175.62989 c 9.91282,22.53012 19.82327,45.05812 29.73129,67.58389" - sodipodi:nodetypes="cc" /> - <path - style="display:inline;opacity:1;fill:#ac14ff;fill-opacity:1;stroke:#ac14ff;stroke-width:0.80699998;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3.228, 0.807;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker35935-5-5)" - d="m 523.50111,175.62989 c 10.16587,40.76181 20.3305,81.51868 30.49385,122.27042" - id="path5226-6-2-1-2-4-5-1-5-6-3" - inkscape:connector-curvature="0" - inkscape:path-effect="#path-effect5228-5-1-6-2-9-4-6-1-7-9" - inkscape:original-d="m 523.50111,175.62989 c 10.16704,40.76152 20.33167,81.51839 30.49385,122.27042" - sodipodi:nodetypes="cc" /> <path - style="display:inline;opacity:1;fill:#ac14ff;fill-opacity:1;stroke:#ac14ff;stroke-width:0.88;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3.52, 0.88;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker35935-1)" - d="m 457.99431,185.46823 c 13.07561,8.94945 26.1492,17.89751 39.22072,26.84415" - id="path5226-6-2-1-2-4-5-1-5-0" + style="display:inline;opacity:1;fill:#ac14db;fill-opacity:1;stroke:#ac14ff;stroke-width:0.75503534;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3.02014133, 0.75503534;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker35935-1-6-5)" + d="m 459.25963,298.68538 c 12.4298,0.0326 24.85706,0.0653 37.28169,0.0979" + id="path5226-6-2-1-2-4-5-1-5-0-2-9" inkscape:connector-curvature="0" - inkscape:path-effect="#path-effect5228-5-1-6-2-9-4-6-1-2" - inkscape:original-d="m 457.99431,185.46823 c 13.0764,8.9483 26.14999,17.89636 39.22072,26.84415" + inkscape:path-effect="#path-effect5228-5-1-6-2-9-4-6-1-2-9-2" + inkscape:original-d="m 459.25963,298.68538 c 12.4298,0.0316 24.85706,0.0643 37.28169,0.0979" sodipodi:nodetypes="cc" /> <path - style="display:inline;opacity:1;fill:#ac14ff;fill-opacity:1;stroke:#ac14ff;stroke-width:0.80699998;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3.228, 0.807;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker35935-1-6)" - d="m 459.47717,245.71809 c 12.28232,-4.96638 24.56173,-9.93159 36.83817,-14.89559" - id="path5226-6-2-1-2-4-5-1-5-0-2" + style="display:inline;opacity:1;fill:#ac14db;fill-opacity:1;stroke:#ac14ff;stroke-width:0.77332252;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3.09329006, 0.77332252;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker35935-1-6-5-1)" + d="m 458.61908,243.27181 c 12.91755,-0.0156 25.83246,-0.0312 38.74462,-0.0468" + id="path5226-6-2-1-2-4-5-1-5-0-2-9-0" inkscape:connector-curvature="0" - inkscape:path-effect="#path-effect5228-5-1-6-2-9-4-6-1-2-9" - inkscape:original-d="m 459.47717,245.71809 c 12.28211,-4.96689 24.56152,-9.9321 36.83817,-14.89559" + inkscape:path-effect="#path-effect5228-5-1-6-2-9-4-6-1-2-9-2-7" + inkscape:original-d="m 458.61908,243.27181 c 12.91755,-0.0166 25.83246,-0.0322 38.74462,-0.0468" sodipodi:nodetypes="cc" /> <path - style="display:inline;opacity:1;fill:#ac14ff;fill-opacity:1;stroke:#ac14ff;stroke-width:0.80699998;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3.228, 0.807;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker35935-1-6-6)" - d="m 459.54824,301.10401 c 12.64219,-20.37548 25.28189,-40.74696 37.91905,-61.11434" - id="path5226-6-2-1-2-4-5-1-5-0-2-9" + style="display:inline;opacity:1;fill:#ac14db;fill-opacity:1;stroke:#ac14ff;stroke-width:0.77624762;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3.10499055, 0.77624764;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker35935-1-6-5-9)" + d="m 457.5506,186.45733 c 12.95011,-0.0208 25.89755,-0.0415 38.84226,-0.0623" + id="path5226-6-2-1-2-4-5-1-5-0-2-9-06" inkscape:connector-curvature="0" - inkscape:path-effect="#path-effect5228-5-1-6-2-9-4-6-1-2-9-4" - inkscape:original-d="M 459.54824,301.10401 C 472.1907,280.7287 484.8304,260.35722 497.46729,239.98967" + inkscape:path-effect="#path-effect5228-5-1-6-2-9-4-6-1-2-9-2-6" + inkscape:original-d="m 457.5506,186.45733 c 12.95011,-0.0218 25.89755,-0.0426 38.84226,-0.0623" sodipodi:nodetypes="cc" /> + <rect + style="display:inline;opacity:1;fill:#ffffff;fill-opacity:1;stroke:url(#linearGradient3995-8);stroke-width:1.2090857;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" + id="rect87-6-5-3-79" + width="72.081367" + height="32.405426" + x="499.14511" + y="170.31314" + rx="16.175425" + ry="16.202713" /> <text xml:space="preserve" - style="font-style:normal;font-weight:normal;font-size:9.9315424px;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.82762849" - x="595.27808" - y="136.64076" - id="text5219-2-4-3-3-4-54-8-8" - transform="scale(0.91487885,1.0930409)"><tspan + style="font-style:normal;font-weight:normal;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none" + x="502.77109" + y="189.40137" + id="text5219-2-6-2"><tspan sodipodi:role="line" - x="595.27808" - y="139.22064" - style="font-size:7.17278051px;line-height:1.25;stroke-width:0.82762849" - id="tspan1265-4-6-7" /></text> + x="502.77109" + y="189.40137" + id="tspan5223-0-9-02" + style="font-size:10px;line-height:1.25">port n+m+1</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:10.5946722px;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.88288933" + x="514.66077" + y="225.14934" + id="text5219-2-3-7-2-1-8-3" + transform="scale(0.89243778,1.1205263)"><tspan + sodipodi:role="line" + x="514.66077" + y="225.14934" + style="font-size:7.31033659px;line-height:1.25;stroke-width:0.88288933" + id="tspan883-1-9-7-6">Single link</tspan></text> <rect - style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:url(#linearGradient1920-1);stroke-width:0.86395979;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" - id="rect3736-8-4-9" - width="25.451954" - height="24.448395" - x="499.03128" - y="213.32141" /> + style="display:inline;opacity:1;fill:#ffffff;fill-opacity:1;stroke:url(#linearGradient3995-8-9);stroke-width:1.2090857;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" + id="rect87-6-5-3-79-1" + width="72.081367" + height="32.405426" + x="499.944" + y="226.74811" + rx="16.175425" + ry="16.202713" /> <text xml:space="preserve" - style="font-style:normal;font-weight:normal;font-size:9.9315424px;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.82762849" - x="548.03668" - y="204.31348" - id="text5219-2-4-3-3-4-54-8" - transform="scale(0.91487885,1.0930409)"><tspan + style="font-style:normal;font-weight:normal;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none" + x="504.46329" + y="246.05832" + id="text5219-2-6-1-7"><tspan sodipodi:role="line" - x="548.03668" - y="204.31348" - style="font-size:7.17278051px;line-height:1.25;stroke-width:0.82762849" - id="tspan1265-4-6">Single </tspan><tspan + x="504.46329" + y="246.05832" + id="tspan5223-0-9-0-5" + style="font-size:10px;line-height:1.25">port n+m+2</tspan></text> + <rect + style="display:inline;opacity:1;fill:#ffffff;fill-opacity:1;stroke:url(#linearGradient3995-8-9-9);stroke-width:1.2090857;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" + id="rect87-6-5-3-79-1-7" + width="72.081367" + height="32.405426" + x="499.31168" + y="282.50211" + rx="16.175425" + ry="16.202713" /> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none" + x="512.51819" + y="301.5791" + id="text5219-2-6-1-6-2"><tspan sodipodi:role="line" - x="548.03668" - y="213.27945" - style="font-size:7.17278051px;line-height:1.25;stroke-width:0.82762849" - id="tspan57836">Link Q</tspan></text> + x="512.51819" + y="301.5791" + id="tspan5223-0-9-0-4-2" + style="font-size:10px;line-height:1.25">port n+o</tspan></text> <path - style="display:inline;opacity:1;fill:none;stroke:#f78202;stroke-width:0.89999998;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3.6, 0.9;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#TriangleOutM-5-2-3)" - d="m 356.74765,186.83153 c 15.88009,-0.11696 31.75919,-0.23391 47.6373,-0.35085" - id="path5226-6-2-5" + style="display:inline;opacity:1;fill:#ac14db;fill-opacity:1;stroke:#ac14ff;stroke-width:0.70236319;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:2.80945275, 0.70236319;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker35935-1-6-5-1-0)" + d="m 571.86582,186.42744 c 7.95108,0.0405 15.90052,0.0811 23.84823,0.12159" + id="path5226-6-2-1-2-4-5-1-5-0-2-9-0-1" inkscape:connector-curvature="0" - inkscape:path-effect="#path-effect5228-5-1-61" - inkscape:original-d="m 356.74765,186.83153 c 15.88008,-0.11795 31.75918,-0.2349 47.6373,-0.35085" + inkscape:path-effect="#path-effect5228-5-1-6-2-9-4-6-1-2-9-2-7-6" + inkscape:original-d="m 571.86582,186.42744 c 7.95109,0.0395 15.90052,0.0801 23.84823,0.12159" sodipodi:nodetypes="cc" /> <path - style="display:inline;opacity:1;fill:none;stroke:#f78202;stroke-width:0.89999998;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3.6, 0.9;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#TriangleOutM-5-2-3-0)" - d="m 357.05625,242.97941 c 15.74231,0.0176 31.48469,0.0352 47.22712,0.0528" - id="path5226-6-2-5-5" + style="display:inline;opacity:1;fill:#ac14db;fill-opacity:1;stroke:#ac14ff;stroke-width:0.70236319;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:2.80945275, 0.70236319;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker35935-1-6-5-1-0-0)" + d="m 572.74002,242.8173 c 7.86699,0.091 15.73233,0.18199 23.59597,0.27295" + id="path5226-6-2-1-2-4-5-1-5-0-2-9-0-1-2" inkscape:connector-curvature="0" - inkscape:path-effect="#path-effect5228-5-1-61-1" - inkscape:original-d="m 357.05625,242.97941 c 15.74231,0.0166 31.48469,0.0342 47.22712,0.0528" + inkscape:path-effect="#path-effect5228-5-1-6-2-9-4-6-1-2-9-2-7-6-3" + inkscape:original-d="m 572.74002,242.8173 c 7.867,0.09 15.73234,0.18097 23.59597,0.27295" sodipodi:nodetypes="cc" /> <path - style="display:inline;opacity:1;fill:none;stroke:#f78202;stroke-width:0.89337438;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3.57349763, 0.89337441;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#TriangleOutM-5-2-3-9)" - d="m 356.67155,297.12049 c 15.97521,0.0733 31.94945,0.14663 47.92273,0.21994" - id="path5226-6-2-5-0" + style="display:inline;opacity:1;fill:#ac14db;fill-opacity:1;stroke:#ac14ff;stroke-width:0.70236319;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:2.80945275, 0.70236319;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker35935-1-6-5-1-0-06)" + d="m 571.86429,299.00558 c 8.49934,0.0508 16.99697,0.10162 25.49284,0.15242" + id="path5226-6-2-1-2-4-5-1-5-0-2-9-0-1-5" inkscape:connector-curvature="0" - inkscape:path-effect="#path-effect5228-5-1-61-9" - inkscape:original-d="m 356.67155,297.12049 c 15.97521,0.0723 31.94945,0.14563 47.92273,0.21994" + inkscape:path-effect="#path-effect5228-5-1-6-2-9-4-6-1-2-9-2-7-6-5" + inkscape:original-d="m 571.86429,299.00558 c 8.49935,0.0498 16.99698,0.10062 25.49284,0.15242" sodipodi:nodetypes="cc" /> + <rect + style="display:inline;opacity:1;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient1760-3);stroke-width:0.67135191;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" + id="rect2896-6-7" + width="159.92059" + height="161.38417" + x="495.64883" + y="159.4483" + ry="4.080533" + rx="5.9213624" + inkscape:export-filename="/home/matz/barracuda/rapports/mbuf-api-v2-images/octeon_multi.png" + inkscape:export-xdpi="112" + inkscape:export-ydpi="112" /> <text xml:space="preserve" - style="font-style:normal;font-weight:normal;font-size:9.9315424px;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.82762849" - x="606.06958" - y="346.46628" - id="text5219-2-4-3-3-4-54-8-7" - transform="scale(0.91487885,1.0930409)"><tspan + style="font-style:normal;font-weight:normal;font-size:10.5946722px;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.88288933" + x="515.76257" + y="175.4832" + id="text5219-2-3-7-2-1-8-3-5" + transform="scale(0.89243778,1.1205263)"><tspan sodipodi:role="line" - x="606.06958" - y="346.46628" - style="font-size:7.17278051px;line-height:1.25;stroke-width:0.82762849" - id="tspan1265-4-6-2">(Tx Generic)</tspan></text> + x="515.76257" + y="175.4832" + style="font-size:7.31033659px;line-height:1.25;stroke-width:0.88288933" + id="tspan883-1-9-7-6-3">Single link</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:10.5946722px;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.88288933" + x="515.76501" + y="274.05133" + id="text5219-2-3-7-2-1-8-3-56" + transform="scale(0.89243778,1.1205263)"><tspan + sodipodi:role="line" + x="515.76501" + y="274.05133" + style="font-size:7.31033659px;line-height:1.25;stroke-width:0.88288933" + id="tspan883-1-9-7-6-2">Single link</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none" + x="546.92126" + y="155.57758" + id="text5219-2-4-2"><tspan + sodipodi:role="line" + x="546.92126" + y="155.57758" + id="tspan5223-0-7-70" + style="font-size:10px;line-height:1.25">Tx adapter</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none" + x="468.36612" + y="180.9222" + id="text5219-1-9-4-9-3"><tspan + sodipodi:role="line" + x="468.36612" + y="180.9222" + id="tspan5223-2-3-5-0-6" + style="font-size:10px;line-height:1.25">q3</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none" + x="467.61584" + y="239.3683" + id="text5219-1-9-4-9-3-0"><tspan + sodipodi:role="line" + x="467.61584" + y="239.3683" + id="tspan5223-2-3-5-0-6-6" + style="font-size:10px;line-height:1.25">q4</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none" + x="468.70688" + y="294.45236" + id="text5219-1-9-4-9-3-2"><tspan + sodipodi:role="line" + x="468.70688" + y="294.45236" + id="tspan5223-2-3-5-0-6-61" + style="font-size:10px;line-height:1.25">q5</tspan></text> </g> </svg> diff --git a/doc/guides/tools/img/eventdev_pipeline_atq_test_lockfree.svg b/doc/guides/tools/img/eventdev_pipeline_atq_test_internal_port.svg index d7f10de3..f4393327 100644 --- a/doc/guides/tools/img/eventdev_pipeline_atq_test_lockfree.svg +++ b/doc/guides/tools/img/eventdev_pipeline_atq_test_internal_port.svg @@ -20,8 +20,8 @@ height="288.34286" id="svg3868" version="1.1" - inkscape:version="0.92.2 (5c3e80d, 2017-08-06)" - sodipodi:docname="eventdev_pipeline_atq_test_lockfree.svg" + inkscape:version="0.92.2 2405546, 2018-03-11" + sodipodi:docname="eventdev_pipeline_atq_test_internal_port.svg" sodipodi:version="0.32" inkscape:output_extension="org.inkscape.output.svg.inkscape" enable-background="new"> @@ -2612,17 +2612,17 @@ borderopacity="1.0" inkscape:pageopacity="0.0" inkscape:pageshadow="2" - inkscape:zoom="1.7519532" - inkscape:cx="479.73438" - inkscape:cy="163.58755" + inkscape:zoom="2.0977641" + inkscape:cx="432.03729" + inkscape:cy="135.16016" inkscape:document-units="px" inkscape:current-layer="layer1" showgrid="false" - inkscape:window-width="1920" - inkscape:window-height="1046" - inkscape:window-x="0" - inkscape:window-y="34" - inkscape:window-maximized="1" + inkscape:window-width="1912" + inkscape:window-height="1033" + inkscape:window-x="4" + inkscape:window-y="22" + inkscape:window-maximized="0" fit-margin-top="0.1" fit-margin-left="0.1" fit-margin-right="0.1" @@ -3331,14 +3331,14 @@ <text xml:space="preserve" style="font-style:normal;font-weight:normal;font-size:9.9315424px;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.82762849" - x="602.09888" + x="604.28497" y="347.66293" id="text5219-2-4-3-3-4-54" transform="scale(0.91487885,1.0930409)"><tspan sodipodi:role="line" - x="602.09888" + x="604.28497" y="347.66293" style="font-size:7.17278051px;line-height:1.25;stroke-width:0.82762849" - id="tspan1265-4">(Tx Lock free)</tspan></text> + id="tspan1265-4">(Internal port)</tspan></text> </g> </svg> diff --git a/doc/guides/tools/img/eventdev_pipeline_queue_test_generic.svg b/doc/guides/tools/img/eventdev_pipeline_queue_test_generic.svg index 732d4886..9fe743f3 100644 --- a/doc/guides/tools/img/eventdev_pipeline_queue_test_generic.svg +++ b/doc/guides/tools/img/eventdev_pipeline_queue_test_generic.svg @@ -20,7 +20,7 @@ height="288.34286" id="svg3868" version="1.1" - inkscape:version="0.92.2 (5c3e80d, 2017-08-06)" + inkscape:version="0.92.2 2405546, 2018-03-11" sodipodi:docname="eventdev_pipeline_queue_test_generic.svg" sodipodi:version="0.32" inkscape:output_extension="org.inkscape.output.svg.inkscape" @@ -28,6 +28,14 @@ <defs id="defs3870"> <linearGradient + id="linearGradient6820" + osb:paint="solid"> + <stop + style="stop-color:#008080;stop-opacity:1;" + offset="0" + id="stop6818" /> + </linearGradient> + <linearGradient id="linearGradient6916" osb:paint="solid"> <stop @@ -1312,7 +1320,7 @@ x2="651.55652" y2="243.36557" gradientUnits="userSpaceOnUse" - gradientTransform="matrix(0.76448972,0,0,0.86504892,-92.637138,19.716473)" /> + gradientTransform="matrix(0.76448972,0,0,0.78486608,-92.637138,48.19976)" /> <linearGradient inkscape:collect="always" xlink:href="#linearGradient3808" @@ -2175,22 +2183,6 @@ y2="232.36095" gradientUnits="userSpaceOnUse" gradientTransform="translate(17.692568,-46.20799)" /> - <marker - inkscape:stockid="TriangleOutM" - orient="auto" - refY="0" - refX="0" - id="marker35935-1" - style="overflow:visible" - inkscape:isstock="true" - inkscape:collect="always"> - <path - id="path35933-49" - d="M 5.77,0 -2.88,5 V -5 Z" - style="fill:#ac14ff;fill-opacity:1;fill-rule:evenodd;stroke:#ac14ff;stroke-width:1.00000003pt;stroke-opacity:1" - transform="scale(0.4)" - inkscape:connector-curvature="0" /> - </marker> <inkscape:path-effect effect="bspline" id="path-effect5228-5-1-6-2-9-4-6-1-2" @@ -2201,22 +2193,6 @@ apply_no_weight="true" apply_with_weight="true" only_selected="false" /> - <marker - inkscape:stockid="TriangleOutM" - orient="auto" - refY="0" - refX="0" - id="marker35935-1-6" - style="overflow:visible" - inkscape:isstock="true" - inkscape:collect="always"> - <path - id="path35933-49-8" - d="M 5.77,0 -2.88,5 V -5 Z" - style="fill:#ac14db;fill-opacity:1;fill-rule:evenodd;stroke:#ac14ff;stroke-width:1.00000003pt;stroke-opacity:1" - transform="scale(0.4)" - inkscape:connector-curvature="0" /> - </marker> <inkscape:path-effect effect="bspline" id="path-effect5228-5-1-6-2-9-4-6-1-2-9" @@ -2227,22 +2203,6 @@ apply_no_weight="true" apply_with_weight="true" only_selected="false" /> - <marker - inkscape:stockid="TriangleOutM" - orient="auto" - refY="0" - refX="0" - id="marker35935-1-6-6" - style="overflow:visible" - inkscape:isstock="true" - inkscape:collect="always"> - <path - id="path35933-49-8-6" - d="M 5.77,0 -2.88,5 V -5 Z" - style="fill:#ac14e4;fill-opacity:1;fill-rule:evenodd;stroke:#ac14ff;stroke-width:1.00000003pt;stroke-opacity:1" - transform="scale(0.4)" - inkscape:connector-curvature="0" /> - </marker> <inkscape:path-effect effect="bspline" id="path-effect5228-5-1-6-2-9-4-6-1-2-9-4" @@ -2403,16 +2363,6 @@ apply_no_weight="true" apply_with_weight="true" only_selected="false" /> - <linearGradient - inkscape:collect="always" - xlink:href="#linearGradient3438" - id="linearGradient16362" - gradientUnits="userSpaceOnUse" - gradientTransform="translate(2.283166,-2.283166)" - x1="534.06958" - y1="163.49922" - x2="580.73291" - y2="163.49922" /> <marker inkscape:isstock="true" style="overflow:visible" @@ -2488,16 +2438,6 @@ effect="spiro" id="path-effect14461-7-5-1" is_visible="true" /> - <linearGradient - inkscape:collect="always" - xlink:href="#linearGradient3993" - id="linearGradient1924-3" - x1="597.00317" - y1="156.97769" - x2="637.13684" - y2="156.97769" - gradientUnits="userSpaceOnUse" - gradientTransform="matrix(0.78531244,0,0,1,50.143534,82.69878)" /> <marker inkscape:stockid="TriangleOutM" orient="auto" @@ -2576,25 +2516,75 @@ apply_no_weight="true" apply_with_weight="true" only_selected="false" /> + <inkscape:path-effect + effect="bspline" + id="path-effect5228-5-1-6-2-9-4-6-1-2-6" + is_visible="true" + weight="33.333333" + steps="2" + helper_size="0" + apply_no_weight="true" + apply_with_weight="true" + only_selected="false" /> + <inkscape:path-effect + effect="bspline" + id="path-effect5228-5-1-6-2-9-4-6-1-2-0" + is_visible="true" + weight="33.333333" + steps="2" + helper_size="0" + apply_no_weight="true" + apply_with_weight="true" + only_selected="false" /> + <inkscape:path-effect + effect="bspline" + id="path-effect5228-5-1-6-2-9-4-6-1-2-0-7" + is_visible="true" + weight="33.333333" + steps="2" + helper_size="0" + apply_no_weight="true" + apply_with_weight="true" + only_selected="false" /> + <inkscape:path-effect + effect="bspline" + id="path-effect5228-5-1-6-2-9-4-6-1-2-0-6" + is_visible="true" + weight="33.333333" + steps="2" + helper_size="0" + apply_no_weight="true" + apply_with_weight="true" + only_selected="false" /> + <inkscape:path-effect + effect="bspline" + id="path-effect5228-5-1-6-2-9-4-6-1-2-9-5" + is_visible="true" + weight="33.333333" + steps="2" + helper_size="0" + apply_no_weight="true" + apply_with_weight="true" + only_selected="false" /> <marker inkscape:stockid="TriangleOutM" orient="auto" refY="0" refX="0" - id="marker35935-1-2" + id="marker35935-1-6-5" style="overflow:visible" inkscape:isstock="true" inkscape:collect="always"> <path - id="path35933-49-6" + id="path35933-49-8-6" d="M 5.77,0 -2.88,5 V -5 Z" - style="fill:#ac14ff;fill-opacity:1;fill-rule:evenodd;stroke:#ac14ff;stroke-width:1.00000003pt;stroke-opacity:1" + style="fill:#ac14db;fill-opacity:1;fill-rule:evenodd;stroke:#ac14ff;stroke-width:1.00000003pt;stroke-opacity:1" transform="scale(0.4)" inkscape:connector-curvature="0" /> </marker> <inkscape:path-effect effect="bspline" - id="path-effect5228-5-1-6-2-9-4-6-1-2-6" + id="path-effect5228-5-1-6-2-9-4-6-1-2-9-2" is_visible="true" weight="33.333333" steps="2" @@ -2607,20 +2597,20 @@ orient="auto" refY="0" refX="0" - id="marker35935-1-9" + id="marker35935-1-6-5-1" style="overflow:visible" inkscape:isstock="true" inkscape:collect="always"> <path - id="path35933-49-5" + id="path35933-49-8-6-2" d="M 5.77,0 -2.88,5 V -5 Z" - style="fill:#ac14ff;fill-opacity:1;fill-rule:evenodd;stroke:#ac14ff;stroke-width:1.00000003pt;stroke-opacity:1" + style="fill:#ac14db;fill-opacity:1;fill-rule:evenodd;stroke:#ac14ff;stroke-width:1.00000003pt;stroke-opacity:1" transform="scale(0.4)" inkscape:connector-curvature="0" /> </marker> <inkscape:path-effect effect="bspline" - id="path-effect5228-5-1-6-2-9-4-6-1-2-0" + id="path-effect5228-5-1-6-2-9-4-6-1-2-9-2-7" is_visible="true" weight="33.333333" steps="2" @@ -2633,20 +2623,20 @@ orient="auto" refY="0" refX="0" - id="marker35935-1-9-7" + id="marker35935-1-6-5-9" style="overflow:visible" inkscape:isstock="true" inkscape:collect="always"> <path - id="path35933-49-5-1" + id="path35933-49-8-6-3" d="M 5.77,0 -2.88,5 V -5 Z" - style="fill:#ac14ff;fill-opacity:1;fill-rule:evenodd;stroke:#ac14ff;stroke-width:1.00000003pt;stroke-opacity:1" + style="fill:#ac14db;fill-opacity:1;fill-rule:evenodd;stroke:#ac14ff;stroke-width:1.00000003pt;stroke-opacity:1" transform="scale(0.4)" inkscape:connector-curvature="0" /> </marker> <inkscape:path-effect effect="bspline" - id="path-effect5228-5-1-6-2-9-4-6-1-2-0-7" + id="path-effect5228-5-1-6-2-9-4-6-1-2-9-2-6" is_visible="true" weight="33.333333" steps="2" @@ -2654,25 +2644,107 @@ apply_no_weight="true" apply_with_weight="true" only_selected="false" /> + <linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient3995-8" + x1="155.21329" + y1="231.61366" + x2="207.95523" + y2="231.61366" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.3938205,0,0,0.9944124,300.23326,-43.855196)" /> + <linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient3995-8-9" + x1="155.21329" + y1="231.61366" + x2="207.95523" + y2="231.61366" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.3938205,0,0,0.9944124,301.03213,12.579775)" /> + <linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient3995-8-9-9" + x1="155.21329" + y1="231.61366" + x2="207.95523" + y2="231.61366" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(1.3938205,0,0,0.9944124,300.39986,68.333755)" /> <marker inkscape:stockid="TriangleOutM" orient="auto" refY="0" refX="0" - id="marker35935-1-9-72" + id="marker35935-1-6-5-1-0" style="overflow:visible" inkscape:isstock="true" inkscape:collect="always"> <path - id="path35933-49-5-2" + id="path35933-49-8-6-2-3" d="M 5.77,0 -2.88,5 V -5 Z" - style="fill:#ac14ff;fill-opacity:1;fill-rule:evenodd;stroke:#ac14ff;stroke-width:1.00000003pt;stroke-opacity:1" + style="fill:#ac14db;fill-opacity:1;fill-rule:evenodd;stroke:#ac14ff;stroke-width:1.00000003pt;stroke-opacity:1" transform="scale(0.4)" inkscape:connector-curvature="0" /> </marker> <inkscape:path-effect effect="bspline" - id="path-effect5228-5-1-6-2-9-4-6-1-2-0-6" + id="path-effect5228-5-1-6-2-9-4-6-1-2-9-2-7-6" + is_visible="true" + weight="33.333333" + steps="2" + helper_size="0" + apply_no_weight="true" + apply_with_weight="true" + only_selected="false" /> + <marker + inkscape:stockid="TriangleOutM" + orient="auto" + refY="0" + refX="0" + id="marker35935-1-6-5-1-0-0" + style="overflow:visible" + inkscape:isstock="true" + inkscape:collect="always"> + <path + id="path35933-49-8-6-2-3-6" + d="M 5.77,0 -2.88,5 V -5 Z" + style="fill:#ac14db;fill-opacity:1;fill-rule:evenodd;stroke:#ac14ff;stroke-width:1.00000003pt;stroke-opacity:1" + transform="scale(0.4)" + inkscape:connector-curvature="0" /> + </marker> + <inkscape:path-effect + effect="bspline" + id="path-effect5228-5-1-6-2-9-4-6-1-2-9-2-7-6-3" + is_visible="true" + weight="33.333333" + steps="2" + helper_size="0" + apply_no_weight="true" + apply_with_weight="true" + only_selected="false" /> + <marker + inkscape:stockid="TriangleOutM" + orient="auto" + refY="0" + refX="0" + id="marker35935-1-6-5-1-0-06" + style="overflow:visible" + inkscape:isstock="true" + inkscape:collect="always"> + <path + id="path35933-49-8-6-2-3-1" + d="M 5.77,0 -2.88,5 V -5 Z" + style="fill:#ac14db;fill-opacity:1;fill-rule:evenodd;stroke:#ac14ff;stroke-width:1.00000003pt;stroke-opacity:1" + transform="scale(0.4)" + inkscape:connector-curvature="0" /> + </marker> + <inkscape:path-effect + effect="bspline" + id="path-effect5228-5-1-6-2-9-4-6-1-2-9-2-7-6-5" is_visible="true" weight="33.333333" steps="2" @@ -2680,6 +2752,16 @@ apply_no_weight="true" apply_with_weight="true" only_selected="false" /> + <linearGradient + inkscape:collect="always" + xlink:href="#linearGradient3993" + id="linearGradient1760-3" + x1="405.34961" + y1="243.36557" + x2="651.55652" + y2="243.36557" + gradientUnits="userSpaceOnUse" + gradientTransform="matrix(0.65213006,0,0,0.72134316,249.13234,64.538752)" /> </defs> <sodipodi:namedview id="base" @@ -2689,16 +2771,16 @@ inkscape:pageopacity="0.0" inkscape:pageshadow="2" inkscape:zoom="1.7519532" - inkscape:cx="423.24137" - inkscape:cy="157.27924" + inkscape:cx="265.48225" + inkscape:cy="64.618341" inkscape:document-units="px" inkscape:current-layer="layer1" showgrid="false" - inkscape:window-width="1920" - inkscape:window-height="1046" - inkscape:window-x="1920" - inkscape:window-y="34" - inkscape:window-maximized="1" + inkscape:window-width="1912" + inkscape:window-height="1033" + inkscape:window-x="4" + inkscape:window-y="22" + inkscape:window-maximized="0" fit-margin-top="0.1" fit-margin-left="0.1" fit-margin-right="0.1" @@ -2762,13 +2844,13 @@ id="tspan5223-0" style="font-size:10px;line-height:1.25">producer 0</tspan></text> <rect - style="display:inline;opacity:1;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient1760);stroke-width:0.7960096;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" + style="display:inline;opacity:1;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient1760);stroke-width:0.75822091;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" id="rect2896-6" width="187.47435" - height="193.53508" + height="175.59599" x="217.62262" - y="133.47206" - ry="4.8934555" + y="151.41115" + ry="4.4398727" rx="6.9415913" inkscape:export-filename="/home/matz/barracuda/rapports/mbuf-api-v2-images/octeon_multi.png" inkscape:export-xdpi="112" @@ -2824,7 +2906,7 @@ x="115.44385" y="186.49918" id="tspan5223-0-9" - style="font-size:10px;line-height:1.25">port n+2</tspan></text> + style="font-size:10px;line-height:1.25">port n+1</tspan></text> <rect style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:url(#linearGradient1920);stroke-width:1.06814909;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" id="rect3736-8-4" @@ -2940,7 +3022,7 @@ x="115.35846" y="242.55573" id="tspan5223-0-9-0" - style="font-size:10px;line-height:1.25">port n+3</tspan></text> + style="font-size:10px;line-height:1.25">port n+2</tspan></text> <rect style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:url(#linearGradient1920-2);stroke-width:1.06814909;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" id="rect3736-8-4-6" @@ -3098,7 +3180,7 @@ x="199.11482" y="111.36845" id="tspan5223-10" - style="font-size:9.02731705px;line-height:1.25;stroke-width:0.90273178">total queues = (number of stages * number of ethernet dev) + 1</tspan></text> + style="font-size:9.02731705px;line-height:1.25;stroke-width:0.90273178">total queues = (number of stages * number of ethernet dev) + number of ethernet dev</tspan></text> <text xml:space="preserve" style="font-style:normal;font-weight:normal;font-size:11.11939621px;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.92661637" @@ -3243,33 +3325,33 @@ <text xml:space="preserve" style="font-style:normal;font-weight:normal;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none" - x="426.57141" + x="428.57141" y="167.14041" id="text5219-2-4"><tspan sodipodi:role="line" - x="426.57141" + x="428.57141" y="167.14041" id="tspan5223-0-7" style="font-size:10px;line-height:1.25">worker 0</tspan></text> <text xml:space="preserve" style="font-style:normal;font-weight:normal;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none" - x="428.30768" + x="430.30768" y="223.46143" id="text5219-2-4-3"><tspan sodipodi:role="line" - x="428.30768" + x="430.30768" y="223.46143" id="tspan5223-0-7-7" style="font-size:10px;line-height:1.25">worker 1</tspan></text> <text xml:space="preserve" style="font-style:normal;font-weight:normal;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none" - x="426.30768" + x="428.30768" y="279.46143" id="text5219-2-4-3-4-2"><tspan sodipodi:role="line" - x="426.30768" + x="428.30768" y="279.46143" id="tspan5223-0-7-7-5-5" style="font-size:10px;line-height:1.25">worker n</tspan></text> @@ -3309,7 +3391,7 @@ <g style="display:inline;opacity:1" id="g20550" - transform="translate(65.401608,-190.91553)"> + transform="translate(87.401608,-194.91553)"> <rect ry="16.293755" rx="11.6051" @@ -3340,7 +3422,7 @@ <g style="display:inline;opacity:1" id="g13899" - transform="translate(-17.21182,-3.304662)"> + transform="translate(5.9319927,-3.304662)"> <rect ry="16.293755" rx="11.6051" @@ -3371,7 +3453,7 @@ <g style="display:inline;opacity:1" id="g13911" - transform="translate(-15.21182,-1.304662)"> + transform="translate(7.6443673,-2.7338705)"> <rect ry="16.293755" rx="11.6051" @@ -3399,83 +3481,6 @@ x="621.71729" sodipodi:role="line"> Txq 0</tspan></text> </g> - <g - style="display:inline;opacity:1" - id="g16360" - transform="matrix(1.0983058,0,0,1.0572541,-82.192809,-6.5664741)"> - <ellipse - ry="24.258638" - rx="22.831659" - cy="161.21605" - cx="559.68445" - id="path8843" - style="fill:#ffffff;fill-opacity:0.98039216;stroke:url(#linearGradient16362);stroke-opacity:1" /> - <text - transform="scale(0.94727182,1.0556632)" - id="text5219-2-4-3-3-4-5" - y="151.93637" - x="571.61011" - style="font-style:normal;font-weight:normal;font-size:10.76524448px;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.89710373" - xml:space="preserve"><tspan - id="tspan1265-5" - style="font-size:7.77489901px;line-height:1.25;stroke-width:0.89710373" - y="151.93637" - x="571.61011" - sodipodi:role="line">Tx Service</tspan><tspan - style="font-size:7.77489901px;line-height:1.25;stroke-width:0.89710373" - y="161.655" - x="571.61011" - sodipodi:role="line" - id="tspan40484">port n + 1</tspan></text> - </g> - <path - style="display:inline;opacity:1;fill:#ac14ff;fill-opacity:1;stroke:#ac14ff;stroke-width:0.80699998;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3.228, 0.807;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker35935-1)" - d="m 475.41709,184.68945 c 14.66204,14.27312 29.32201,28.54422 43.97988,42.81328" - id="path5226-6-2-1-2-4-5-1-5-0" - inkscape:connector-curvature="0" - inkscape:path-effect="#path-effect5228-5-1-6-2-9-4-6-1-2" - inkscape:original-d="m 475.41709,184.68945 c 14.66303,14.2721 29.323,28.54321 43.97988,42.81328" - sodipodi:nodetypes="cc" /> - <path - style="display:inline;opacity:1;fill:#ac14db;fill-opacity:1;stroke:#ac14ff;stroke-width:0.80699998;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3.228, 0.807;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker35935-1-6)" - d="m 476.32916,241.51456 c 13.86102,-0.34 27.7191,-0.67992 41.57417,-1.01977" - id="path5226-6-2-1-2-4-5-1-5-0-2" - inkscape:connector-curvature="0" - inkscape:path-effect="#path-effect5228-5-1-6-2-9-4-6-1-2-9" - inkscape:original-d="m 476.32916,241.51456 c 13.861,-0.34097 27.71908,-0.6809 41.57417,-1.01977" - sodipodi:nodetypes="cc" /> - <path - style="display:inline;opacity:1;fill:#ac14e4;fill-opacity:1;stroke:#ac14ff;stroke-width:0.80699998;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3.228, 0.807;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker35935-1-6-6)" - d="m 474.31327,298.61285 c 15.031,-15.59075 30.05891,-31.17831 45.0837,-46.76263" - id="path5226-6-2-1-2-4-5-1-5-0-2-9" - inkscape:connector-curvature="0" - inkscape:path-effect="#path-effect5228-5-1-6-2-9-4-6-1-2-9-4" - inkscape:original-d="m 474.31327,298.61285 c 15.03102,-15.59073 30.05893,-31.17829 45.0837,-46.76263" - sodipodi:nodetypes="cc" /> - <rect - style="display:inline;opacity:1;fill:none;fill-opacity:1;stroke:url(#linearGradient1924-3);stroke-width:0.94657081;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" - id="rect3736-8-0-1-7-7" - width="30.678661" - height="24.347494" - x="519.39697" - y="227.50273" /> - <text - xml:space="preserve" - style="font-style:normal;font-weight:normal;font-size:9.9315424px;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.82762849" - x="571.69696" - y="217.79964" - id="text5219-2-4-3-3-4-54-8-7-5" - transform="scale(0.91487885,1.0930409)"><tspan - sodipodi:role="line" - x="571.69696" - y="217.79964" - style="font-size:7.17278051px;line-height:1.25;stroke-width:0.82762849" - id="tspan1265-4-6-2-3">Single</tspan><tspan - sodipodi:role="line" - x="571.69696" - y="226.76561" - style="font-size:7.17278051px;line-height:1.25;stroke-width:0.82762849" - id="tspan6344">Link Q</tspan></text> <path style="display:inline;opacity:1;fill:none;stroke:#f78202;stroke-width:1.01153409;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#TriangleOutM-5-2-6-6)" d="m 391.11413,240.54267 c 10.00574,0.0714 20.0096,0.14275 30.01154,0.21411" @@ -3500,49 +3505,184 @@ inkscape:path-effect="#path-effect5228-5-1-6-84-8" inkscape:original-d="m 389.52644,184.04076 c 10.2068,0.0715 20.41172,0.14408 30.61473,0.21761" sodipodi:nodetypes="cc" /> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:9.9315424px;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.82762849" + x="665.00641" + y="346.51425" + id="text5219-2-4-3-3-4-54-8-7" + transform="scale(0.91487885,1.0930409)"><tspan + sodipodi:role="line" + x="665.00641" + y="346.51425" + style="font-size:7.17278051px;line-height:1.25;stroke-width:0.82762849" + id="tspan1265-4-6-2">(Tx Generic)</tspan></text> <path - style="display:inline;opacity:1;fill:#ac14ff;fill-opacity:1;stroke:#ac14ff;stroke-width:0.80699998;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3.228, 0.807;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker35935-1-2)" - d="m 533.61005,227.17178 c -0.11895,-11.90475 -0.23788,-23.80683 -0.35678,-35.70623" - id="path5226-6-2-1-2-4-5-1-5-0-4" + style="display:inline;opacity:1;fill:#ac14db;fill-opacity:1;stroke:#ac14ff;stroke-width:0.77748054;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3.10992218, 0.77748055;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker35935-1-6-5)" + d="m 475.15346,298.63383 c 13.1798,0.0326 26.3569,0.0653 39.53121,0.0979" + id="path5226-6-2-1-2-4-5-1-5-0-2-9" inkscape:connector-curvature="0" - inkscape:path-effect="#path-effect5228-5-1-6-2-9-4-6-1-2-6" - inkscape:original-d="m 533.61005,227.17178 c -0.11794,-11.90476 -0.23687,-23.80684 -0.35678,-35.70623" + inkscape:path-effect="#path-effect5228-5-1-6-2-9-4-6-1-2-9-2" + inkscape:original-d="m 475.15346,298.63383 c 13.1798,0.0316 26.3569,0.0643 39.53121,0.0979" sodipodi:nodetypes="cc" /> <path - style="display:inline;opacity:1;fill:#ac14ff;fill-opacity:1;stroke:#ac14ff;stroke-width:0.80699998;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3.228, 0.807;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker35935-1-9)" - d="m 554.18303,173.89676 c 12.12572,3.64515 24.2491,7.2896 36.37012,10.93334" - id="path5226-6-2-1-2-4-5-1-5-0-48" + style="display:inline;opacity:1;fill:#ac14db;fill-opacity:1;stroke:#ac14ff;stroke-width:0.77332252;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3.09329006, 0.77332252;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker35935-1-6-5-1)" + d="m 476.76243,243.22025 c 12.91755,-0.0156 25.83246,-0.0312 38.74462,-0.0468" + id="path5226-6-2-1-2-4-5-1-5-0-2-9-0" inkscape:connector-curvature="0" - inkscape:path-effect="#path-effect5228-5-1-6-2-9-4-6-1-2-0" - inkscape:original-d="m 554.18303,173.89676 c 12.12608,3.64396 24.24946,7.28841 36.37012,10.93334" + inkscape:path-effect="#path-effect5228-5-1-6-2-9-4-6-1-2-9-2-7" + inkscape:original-d="m 476.76243,243.22025 c 12.91755,-0.0166 25.83246,-0.0322 38.74462,-0.0468" sodipodi:nodetypes="cc" /> <path - style="display:inline;opacity:1;fill:#ac14ff;fill-opacity:1;stroke:#ac14ff;stroke-width:0.80699998;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3.228, 0.807;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker35935-1-9-7)" - d="m 554.18303,173.89676 c 12.8469,22.86455 25.6922,45.72625 38.53585,68.585" - id="path5226-6-2-1-2-4-5-1-5-0-48-2" + style="display:inline;opacity:1;fill:#ac14db;fill-opacity:1;stroke:#ac14ff;stroke-width:0.77624762;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3.10499055, 0.77624764;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker35935-1-6-5-9)" + d="m 475.69395,186.40577 c 12.95011,-0.0208 25.89755,-0.0415 38.84226,-0.0623" + id="path5226-6-2-1-2-4-5-1-5-0-2-9-06" inkscape:connector-curvature="0" - inkscape:path-effect="#path-effect5228-5-1-6-2-9-4-6-1-2-0-7" - inkscape:original-d="m 554.18303,173.89676 c 12.84809,22.86388 25.69339,45.72558 38.53585,68.585" + inkscape:path-effect="#path-effect5228-5-1-6-2-9-4-6-1-2-9-2-6" + inkscape:original-d="m 475.69395,186.40577 c 12.95011,-0.0218 25.89755,-0.0426 38.84226,-0.0623" sodipodi:nodetypes="cc" /> + <rect + style="display:inline;opacity:1;fill:#ffffff;fill-opacity:1;stroke:url(#linearGradient3995-8);stroke-width:1.2090857;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" + id="rect87-6-5-3-79" + width="72.081367" + height="32.405426" + x="517.28845" + y="170.26158" + rx="16.175425" + ry="16.202713" /> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none" + x="520.91443" + y="189.34982" + id="text5219-2-6-2"><tspan + sodipodi:role="line" + x="520.91443" + y="189.34982" + id="tspan5223-0-9-02" + style="font-size:10px;line-height:1.25">port n+m+1</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:10.5946722px;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.88288933" + x="534.99072" + y="225.10315" + id="text5219-2-3-7-2-1-8-3" + transform="scale(0.89243779,1.1205263)"><tspan + sodipodi:role="line" + x="534.99072" + y="225.10315" + style="font-size:7.31033659px;line-height:1.25;stroke-width:0.88288933" + id="tspan883-1-9-7-6">Single link</tspan></text> + <rect + style="display:inline;opacity:1;fill:#ffffff;fill-opacity:1;stroke:url(#linearGradient3995-8-9);stroke-width:1.2090857;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" + id="rect87-6-5-3-79-1" + width="72.081367" + height="32.405426" + x="518.08734" + y="226.69656" + rx="16.175425" + ry="16.202713" /> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none" + x="522.60663" + y="246.00677" + id="text5219-2-6-1-7"><tspan + sodipodi:role="line" + x="522.60663" + y="246.00677" + id="tspan5223-0-9-0-5" + style="font-size:10px;line-height:1.25">port n+m+2</tspan></text> + <rect + style="display:inline;opacity:1;fill:#ffffff;fill-opacity:1;stroke:url(#linearGradient3995-8-9-9);stroke-width:1.2090857;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" + id="rect87-6-5-3-79-1-7" + width="72.081367" + height="32.405426" + x="517.45502" + y="282.45056" + rx="16.175425" + ry="16.202713" /> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none" + x="530.6615" + y="301.52756" + id="text5219-2-6-1-6-2"><tspan + sodipodi:role="line" + x="530.6615" + y="301.52756" + id="tspan5223-0-9-0-4-2" + style="font-size:10px;line-height:1.25">port n+o</tspan></text> <path - style="display:inline;opacity:1;fill:#ac14ff;fill-opacity:1;stroke:#ac14ff;stroke-width:0.80699998;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:3.228, 0.807;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker35935-1-9-72)" - d="m 554.18303,173.89676 c 12.65661,41.60787 25.31164,83.21054 37.96507,124.80795" - id="path5226-6-2-1-2-4-5-1-5-0-48-1" + style="display:inline;opacity:1;fill:#ac14db;fill-opacity:1;stroke:#ac14ff;stroke-width:0.70236319;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:2.80945275, 0.70236319;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker35935-1-6-5-1-0)" + d="m 590.00917,186.37588 c 7.95108,0.0405 15.90052,0.0811 23.84823,0.12159" + id="path5226-6-2-1-2-4-5-1-5-0-2-9-0-1" inkscape:connector-curvature="0" - inkscape:path-effect="#path-effect5228-5-1-6-2-9-4-6-1-2-0-6" - inkscape:original-d="m 554.18303,173.89676 c 12.65781,41.6075 25.31284,83.21018 37.96507,124.80795" + inkscape:path-effect="#path-effect5228-5-1-6-2-9-4-6-1-2-9-2-7-6" + inkscape:original-d="m 590.00917,186.37588 c 7.95109,0.0395 15.90052,0.0801 23.84823,0.12159" sodipodi:nodetypes="cc" /> + <path + style="display:inline;opacity:1;fill:#ac14db;fill-opacity:1;stroke:#ac14ff;stroke-width:0.70236319;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:2.80945275, 0.70236319;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker35935-1-6-5-1-0-0)" + d="m 590.88337,242.76574 c 7.86699,0.091 15.73233,0.18199 23.59597,0.27295" + id="path5226-6-2-1-2-4-5-1-5-0-2-9-0-1-2" + inkscape:connector-curvature="0" + inkscape:path-effect="#path-effect5228-5-1-6-2-9-4-6-1-2-9-2-7-6-3" + inkscape:original-d="m 590.88337,242.76574 c 7.867,0.09 15.73234,0.18097 23.59597,0.27295" + sodipodi:nodetypes="cc" /> + <path + style="display:inline;opacity:1;fill:#ac14db;fill-opacity:1;stroke:#ac14ff;stroke-width:0.70236319;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:2.80945275, 0.70236319;stroke-dashoffset:0;stroke-opacity:1;marker-end:url(#marker35935-1-6-5-1-0-06)" + d="m 590.00764,298.95403 c 8.49934,0.0508 16.99697,0.10162 25.49284,0.15242" + id="path5226-6-2-1-2-4-5-1-5-0-2-9-0-1-5" + inkscape:connector-curvature="0" + inkscape:path-effect="#path-effect5228-5-1-6-2-9-4-6-1-2-9-2-7-6-5" + inkscape:original-d="m 590.00764,298.95403 c 8.49935,0.0498 16.99698,0.10062 25.49284,0.15242" + sodipodi:nodetypes="cc" /> + <rect + style="display:inline;opacity:1;fill:none;fill-opacity:1;fill-rule:evenodd;stroke:url(#linearGradient1760-3);stroke-width:0.67135191;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1" + id="rect2896-6-7" + width="159.92059" + height="161.38417" + x="513.79218" + y="159.39674" + ry="4.080533" + rx="5.9213624" + inkscape:export-filename="/home/matz/barracuda/rapports/mbuf-api-v2-images/octeon_multi.png" + inkscape:export-xdpi="112" + inkscape:export-ydpi="112" /> <text xml:space="preserve" - style="font-style:normal;font-weight:normal;font-size:9.9315424px;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.82762849" - x="665.00641" - y="346.51425" - id="text5219-2-4-3-3-4-54-8-7" - transform="scale(0.91487885,1.0930409)"><tspan + style="font-style:normal;font-weight:normal;font-size:10.5946722px;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.88288933" + x="536.09253" + y="175.43703" + id="text5219-2-3-7-2-1-8-3-5" + transform="scale(0.89243778,1.1205263)"><tspan sodipodi:role="line" - x="665.00641" - y="346.51425" - style="font-size:7.17278051px;line-height:1.25;stroke-width:0.82762849" - id="tspan1265-4-6-2">(Tx Generic)</tspan></text> + x="536.09253" + y="175.43703" + style="font-size:7.31033659px;line-height:1.25;stroke-width:0.88288933" + id="tspan883-1-9-7-6-3">Single link</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;font-size:10.5946722px;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.88288933" + x="533.85394" + y="274.00516" + id="text5219-2-3-7-2-1-8-3-56" + transform="scale(0.89243778,1.1205263)"><tspan + sodipodi:role="line" + x="533.85394" + y="274.00516" + style="font-size:7.31033659px;line-height:1.25;stroke-width:0.88288933" + id="tspan883-1-9-7-6-2">Single link</tspan></text> + <text + xml:space="preserve" + style="font-style:normal;font-weight:normal;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none" + x="575.06464" + y="155.52603" + id="text5219-2-4-2"><tspan + sodipodi:role="line" + x="575.06464" + y="155.52603" + id="tspan5223-0-7-70" + style="font-size:10px;line-height:1.25">Tx adapter</tspan></text> </g> </svg> diff --git a/doc/guides/tools/img/eventdev_pipeline_queue_test_lockfree.svg b/doc/guides/tools/img/eventdev_pipeline_queue_test_internal_port.svg index c0a365c7..3036ad66 100644 --- a/doc/guides/tools/img/eventdev_pipeline_queue_test_lockfree.svg +++ b/doc/guides/tools/img/eventdev_pipeline_queue_test_internal_port.svg @@ -20,8 +20,8 @@ height="288.34286" id="svg3868" version="1.1" - inkscape:version="0.92.2 (5c3e80d, 2017-08-06)" - sodipodi:docname="eventdev_pipeline_queue_test_lockfree.svg" + inkscape:version="0.92.2 2405546, 2018-03-11" + sodipodi:docname="eventdev_pipeline_queue_test_internal_port.svg" sodipodi:version="0.32" inkscape:output_extension="org.inkscape.output.svg.inkscape" enable-background="new"> @@ -2853,17 +2853,17 @@ borderopacity="1.0" inkscape:pageopacity="0.0" inkscape:pageshadow="2" - inkscape:zoom="2.0000001" - inkscape:cx="394.32532" - inkscape:cy="122.70585" + inkscape:zoom="1.6933595" + inkscape:cx="466.69113" + inkscape:cy="93.384431" inkscape:document-units="px" inkscape:current-layer="layer1" showgrid="false" - inkscape:window-width="1920" - inkscape:window-height="1046" - inkscape:window-x="1920" - inkscape:window-y="34" - inkscape:window-maximized="1" + inkscape:window-width="1912" + inkscape:window-height="1033" + inkscape:window-x="4" + inkscape:window-y="22" + inkscape:window-maximized="0" fit-margin-top="0.1" fit-margin-left="0.1" fit-margin-right="0.1" @@ -3809,7 +3809,7 @@ x="670.83521" y="349.11719" style="font-size:7.17278051px;line-height:1.25;stroke-width:0.82762849" - id="tspan1265-4">(Tx Lock free)</tspan></text> + id="tspan1265-4">(Internal port)</tspan></text> <text xml:space="preserve" style="font-style:normal;font-weight:normal;font-size:11.11939621px;line-height:0%;font-family:'Bitstream Vera Sans';display:inline;opacity:1;fill:#000000;fill-opacity:1;stroke:none;stroke-width:0.92661637" diff --git a/doc/guides/tools/testeventdev.rst b/doc/guides/tools/testeventdev.rst index 46effd87..cddba3be 100644 --- a/doc/guides/tools/testeventdev.rst +++ b/doc/guides/tools/testeventdev.rst @@ -70,6 +70,8 @@ The following are the application command-line options: order_atq perf_queue perf_atq + pipeline_atq + pipeline_queue * ``--socket_id <n>`` @@ -521,8 +523,9 @@ This is a pipeline test case that aims at testing the following: +===+==============+================+=========================================+ | 1 | nb_queues | (nb_producers | Queues will be configured based on the | | | | * nb_stages) + | user requested sched type list(--stlist)| - | | | x | Here value of x is 1 in generic pipeline| - | | | | and nb_producers in lockfree pipeline | + | | | nb_producers | At the last stage of the schedule list | + | | | | the event is enqueued onto per port | + | | | | unique queue which is then Transmitted. | +---+--------------+----------------+-----------------------------------------+ | 2 | nb_producers | >= 1 | Producers will be configured based on | | | | | the number of detected ethernet devices.| @@ -533,17 +536,19 @@ This is a pipeline test case that aims at testing the following: | | | | argument | +---+--------------+----------------+-----------------------------------------+ | 4 | nb_ports | nb_workers + | Workers use port 0 to port n. | - | | | nb_producers | Producers use port n+1 to port n+m, | - | | | | depending on the Rx adapter capability. | + | | | (nb_produces * | Producers use port n+1 to port n+m, | + | | | 2) | depending on the Rx adapter capability. | + | | | | Consumers use port n+m+1 to port n+o | + | | | | depending on the Tx adapter capability. | +---+--------------+----------------+-----------------------------------------+ .. _figure_eventdev_pipeline_queue_test_generic: .. figure:: img/eventdev_pipeline_queue_test_generic.* -.. _figure_eventdev_pipeline_queue_test_lockfree: +.. _figure_eventdev_pipeline_queue_test_internal_port: -.. figure:: img/eventdev_pipeline_queue_test_lockfree.* +.. figure:: img/eventdev_pipeline_queue_test_internal_port.* pipeline queue test operation. @@ -568,10 +573,11 @@ the last stage in the pipeline if the event type is ``atomic`` it is enqueued onto ethdev Tx queue else to maintain ordering the event type is set to ``atomic`` and enqueued onto the last stage queue. -If the ethernet has ``DEV_TX_OFFLOAD_MT_LOCKFREE`` capability then the worker -cores transmit the packets directly. Else the worker cores enqueue the packet -onto the ``SINGLE_LINK_QUEUE`` that is managed by a Tx service. The Tx service -dequeues the packet and transmits it. +If the ethdev and eventdev pair have ``RTE_EVENT_ETH_TX_ADAPTER_CAP_INTERNAL_PORT`` +capability then the worker cores enqueue the packets to the eventdev directly +using ``rte_event_eth_tx_adapter_enqueue`` else the worker cores enqueue the +packet onto the ``SINGLE_LINK_QUEUE`` that is managed by the Tx adapter. +The Tx adapter dequeues the packet and transmits it. On packet Tx, application increments the number events processed and print periodically in one second to get the number of events processed in one @@ -628,8 +634,9 @@ This is a pipeline test case that aims at testing the following with +===+==============+================+=========================================+ | 1 | nb_queues | nb_producers + | Queues will be configured based on the | | | | x | user requested sched type list(--stlist)| - | | | | where x = 1 in generic pipeline and 0 | - | | | | in lockfree pipeline | + | | | | where x = nb_producers in generic | + | | | | pipeline and 0 if all the ethdev | + | | | | being used have Internal port capability| +---+--------------+----------------+-----------------------------------------+ | 2 | nb_producers | >= 1 | Producers will be configured based on | | | | | the number of detected ethernet devices.| @@ -640,17 +647,22 @@ This is a pipeline test case that aims at testing the following with | | | | argument | +---+--------------+----------------+-----------------------------------------+ | 4 | nb_ports | nb_workers + | Workers use port 0 to port n. | - | | | nb_producers | Producers use port n+1 to port n+m, | - | | | | depending on the Rx adapter capability. | + | | | nb_producers + | Producers use port n+1 to port n+m, | + | | | x | depending on the Rx adapter capability. | + | | | | x = nb_producers in generic pipeline and| + | | | | 0 if all the ethdev being used have | + | | | | Internal port capability. | + | | | | Consumers may use port n+m+1 to port n+o| + | | | | depending on the Tx adapter capability. | +---+--------------+----------------+-----------------------------------------+ .. _figure_eventdev_pipeline_atq_test_generic: .. figure:: img/eventdev_pipeline_atq_test_generic.* -.. _figure_eventdev_pipeline_atq_test_lockfree: +.. _figure_eventdev_pipeline_atq_test_internal_port: -.. figure:: img/eventdev_pipeline_atq_test_lockfree.* +.. figure:: img/eventdev_pipeline_atq_test_internal_port.* pipeline atq test operation. |
