diff options
Diffstat (limited to 'doc')
35 files changed, 990 insertions, 666 deletions
diff --git a/doc/build-sdk-meson.txt b/doc/build-sdk-meson.txt index a4dd0919..29a8bd38 100644 --- a/doc/build-sdk-meson.txt +++ b/doc/build-sdk-meson.txt @@ -4,7 +4,7 @@ INSTALLING DPDK USING THE MESON BUILD SYSTEM NOTE: Compiling and installing DPDK using ``meson`` and ``ninja``, rather than using ``make`` (GNU make) is EXPERIMENTAL. Official builds of DPDK should always be done using ``make``, as described in the ``Getting Started -Guide`` documentation, and at "http://dpdk.org/doc/quick-start". +Guide`` documentation, and at "http://core.dpdk.org/doc/quick-start". Summary -------- diff --git a/doc/guides/contributing/coding_style.rst b/doc/guides/contributing/coding_style.rst index 19445c11..d96698a7 100644 --- a/doc/guides/contributing/coding_style.rst +++ b/doc/guides/contributing/coding_style.rst @@ -247,6 +247,15 @@ Structure Declarations * Use of the structures should be by separate variable declarations and those declarations must be extern if they are declared in a header file. * Externally visible structure definitions should have the structure name prefixed by ``rte_`` to avoid namespace collisions. +.. note:: + + Uses of ``bool`` in structures are not preferred as is wastes space and + it's also not clear as to what type size the bool is. A preferred use of + ``bool`` is mainly as a return type from functions that return true/false, + and maybe local variable functions. + + Ref: `LKML <https://lkml.org/lkml/2017/11/21/384>`_ + Queues ~~~~~~ diff --git a/doc/guides/contributing/documentation.rst b/doc/guides/contributing/documentation.rst index 0165990e..c28a95c3 100644 --- a/doc/guides/contributing/documentation.rst +++ b/doc/guides/contributing/documentation.rst @@ -83,7 +83,7 @@ added to by the developer. * **API documentation** The API documentation explains how to use the public DPDK functions. - The `API index page <http://dpdk.org/doc/api/>`_ shows the generated API documentation with related groups of functions. + The `API index page <http://doc.dpdk.org/api/>`_ shows the generated API documentation with related groups of functions. The API documentation should be updated via Doxygen comments when new functions are added. @@ -653,7 +653,7 @@ The following are some guidelines for use of Doxygen in the DPDK API documentati */ In the API documentation the functions will be rendered as links, see the - `online section of the rte_ethdev.h docs <http://dpdk.org/doc/api/rte__ethdev_8h.html>`_ that contains the above text. + `online section of the rte_ethdev.h docs <http://doc.dpdk.org/api/rte__ethdev_8h.html>`_ that contains the above text. * The ``@see`` keyword can be used to create a *see also* link to another file or library. This directive should be placed on one line at the bottom of the documentation section. diff --git a/doc/guides/contributing/patches.rst b/doc/guides/contributing/patches.rst index a3d78802..a64bb036 100644 --- a/doc/guides/contributing/patches.rst +++ b/doc/guides/contributing/patches.rst @@ -28,9 +28,9 @@ The DPDK development process has the following features: * All sub-repositories are merged into main repository for ``-rc1`` and ``-rc2`` versions of the release. * After the ``-rc2`` release all patches should target the main repository. -The mailing list for DPDK development is `dev@dpdk.org <http://dpdk.org/ml/archives/dev/>`_. -Contributors will need to `register for the mailing list <http://dpdk.org/ml/listinfo/dev>`_ in order to submit patches. -It is also worth registering for the DPDK `Patchwork <http://dpdk.org/dev/patchwork/project/dpdk/list/>`_ +The mailing list for DPDK development is `dev@dpdk.org <http://mails.dpdk.org/archives/dev/>`_. +Contributors will need to `register for the mailing list <http://mails.dpdk.org/listinfo/dev>`_ in order to submit patches. +It is also worth registering for the DPDK `Patchwork <http://patches.dpdk.org/project/dpdk/list/>`_ The development process requires some familiarity with the ``git`` version control system. Refer to the `Pro Git Book <http://www.git-scm.com/book/>`_ for further information. @@ -130,7 +130,7 @@ main repository:: git clone git://dpdk.org/dpdk git clone http://dpdk.org/git/dpdk -sub-repositories (`list <http://dpdk.org/browse/next>`_):: +sub-repositories (`list <http://git.dpdk.org/next>`_):: git clone git://dpdk.org/next/dpdk-next-* git clone http://dpdk.org/git/next/dpdk-next-* @@ -169,6 +169,11 @@ Larger changes that require different explanations should be separated into logi A good way of thinking about whether a patch should be split is to consider whether the change could be applied without dependencies as a backport. +It is better to keep the related documentation changes in the same patch +file as the code, rather than one big documentation patch at then end of a +patchset. This makes it easier for future maintenance and development of the +code. + As a guide to how patches should be structured run ``git log`` on similar files. @@ -281,7 +286,7 @@ in the body of the commit message. For example:: Signed-off-by: Alex Smith <alex.smith@example.com> -`Bugzilla <https://dpdk.org/tracker>`_ +`Bugzilla <https://bugs.dpdk.org>`_ is a bug- or issue-tracking system. Bug-tracking systems allow individual or groups of developers effectively to keep track of outstanding problems with their product. @@ -303,7 +308,7 @@ Patch for Stable Releases ~~~~~~~~~~~~~~~~~~~~~~~~~ All fix patches to the master branch that are candidates for backporting -should also be CCed to the `stable@dpdk.org <http://dpdk.org/ml/listinfo/stable>`_ +should also be CCed to the `stable@dpdk.org <http://mails.dpdk.org/listinfo/stable>`_ mailing list. In the commit message body the Cc: stable@dpdk.org should be inserted as follows:: @@ -504,7 +509,7 @@ If the patch is in relation to a previous email thread you can add it to the sam git send-email --to dev@dpdk.org --in-reply-to <1234-foo@bar.com> 000*.patch The Message ID can be found in the raw text of emails or at the top of each Patchwork patch, -`for example <http://dpdk.org/dev/patchwork/patch/7646/>`_. +`for example <http://patches.dpdk.org/patch/7646/>`_. Shallow threading (``--thread --no-chain-reply-to``) is preferred for a patch series. Once submitted your patches will appear on the mailing list and in Patchwork. diff --git a/doc/guides/contributing/stable.rst b/doc/guides/contributing/stable.rst index 1746c046..2ac4f0a8 100644 --- a/doc/guides/contributing/stable.rst +++ b/doc/guides/contributing/stable.rst @@ -96,7 +96,7 @@ The Stable and LTS release are coordinated on the stable@dpdk.org mailing list. All fix patches to the master branch that are candidates for backporting -should also be CCed to the `stable@dpdk.org <http://dpdk.org/ml/listinfo/stable>`_ +should also be CCed to the `stable@dpdk.org <http://mails.dpdk.org/listinfo/stable>`_ mailing list. @@ -107,10 +107,10 @@ A Stable Release will be released by: * Tagging the release with YY.MM.n (year, month, number). * Uploading a tarball of the release to dpdk.org. -* Sending an announcement to the `announce@dpdk.org <http://dpdk.org/ml/listinfo/announce>`_ +* Sending an announcement to the `announce@dpdk.org <http://mails.dpdk.org/listinfo/announce>`_ list. -Stable releases are available on the `dpdk.org download page <http://dpdk.org/download>`_. +Stable releases are available on the `dpdk.org download page <http://core.dpdk.org/download/>`_. ABI diff --git a/doc/guides/cryptodevs/qat.rst b/doc/guides/cryptodevs/qat.rst index 1db98685..9fb9f01d 100644 --- a/doc/guides/cryptodevs/qat.rst +++ b/doc/guides/cryptodevs/qat.rst @@ -7,7 +7,7 @@ Intel(R) QuickAssist (QAT) Crypto Poll Mode Driver 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>`_ +* Details of the `compression service <http://doc.dpdk.org/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. @@ -124,7 +124,7 @@ 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>`_. +`here <http://doc.dpdk.org/guides/linux_gsg/build_dpdk.html>`_. Quick instructions for QAT cryptodev PMD are as follows: diff --git a/doc/guides/freebsd_gsg/freebsd_eal_parameters.rst b/doc/guides/freebsd_gsg/freebsd_eal_parameters.rst new file mode 100644 index 00000000..fba467a2 --- /dev/null +++ b/doc/guides/freebsd_gsg/freebsd_eal_parameters.rst @@ -0,0 +1,20 @@ +.. SPDX-License-Identifier: BSD-3-Clause + Copyright(c) 2018 Intel Corporation. + +EAL parameters +============== + +This document contains a list of all EAL parameters. These parameters can be +used by any DPDK application running on FreeBSD. + +Common EAL parameters +--------------------- + +The following EAL parameters are common to all platforms supported by DPDK. + +.. include:: ../linux_gsg/eal_args.include.rst + +FreeBSD-specific EAL parameters +------------------------------- + +There are currently no FreeBSD-specific EAL command-line parameters available. diff --git a/doc/guides/freebsd_gsg/index.rst b/doc/guides/freebsd_gsg/index.rst index fdb4df32..9af5988d 100644 --- a/doc/guides/freebsd_gsg/index.rst +++ b/doc/guides/freebsd_gsg/index.rst @@ -14,3 +14,4 @@ Getting Started Guide for FreeBSD install_from_ports build_dpdk build_sample_apps + freebsd_eal_parameters diff --git a/doc/guides/freebsd_gsg/install_from_ports.rst b/doc/guides/freebsd_gsg/install_from_ports.rst index d6ce847f..253328eb 100644 --- a/doc/guides/freebsd_gsg/install_from_ports.rst +++ b/doc/guides/freebsd_gsg/install_from_ports.rst @@ -62,7 +62,7 @@ environmental variables should be set as below: .. note:: To install a copy of the DPDK compiled using gcc, please download the - official DPDK package from http://dpdk.org/ and install manually using + official DPDK package from http://core.dpdk.org/download/ and install manually using the instructions given in the next chapter, :ref:`building_from_source` An example application can therefore be copied to a user's home directory and diff --git a/doc/guides/howto/flow_bifurcation.rst b/doc/guides/howto/flow_bifurcation.rst index bc9a0934..eabf4d73 100644 --- a/doc/guides/howto/flow_bifurcation.rst +++ b/doc/guides/howto/flow_bifurcation.rst @@ -268,4 +268,4 @@ The typical procedure to achieve this is as follows: 'not involved', while ``00`` or no mask means 'involved'. * For more details of the configuration, refer to the - `cloud filter test plan <http://dpdk.org/browse/tools/dts/tree/test_plans/cloud_filter_test_plan.rst>`_ + `cloud filter test plan <http://git.dpdk.org/tools/dts/tree/test_plans/cloud_filter_test_plan.rst>`_ diff --git a/doc/guides/linux_gsg/eal_args.include.rst b/doc/guides/linux_gsg/eal_args.include.rst new file mode 100644 index 00000000..cf421a56 --- /dev/null +++ b/doc/guides/linux_gsg/eal_args.include.rst @@ -0,0 +1,146 @@ +.. SPDX-License-Identifier: BSD-3-Clause + Copyright(c) 2018 Intel Corporation. + +Lcore-related options +~~~~~~~~~~~~~~~~~~~~~ + +* ``-c <core mask>`` + + Set the hexadecimal bitmask of the cores to run on. + +* ``-l <core list>`` + + List of cores to run on + + The argument format is ``<c1>[-c2][,c3[-c4],...]`` + where ``c1``, ``c2``, etc are core indexes between 0 and 128. + +* ``--lcores <core map>`` + + Map lcore set to physical cpu set + + The argument format is:: + + <lcores[@cpus]>[<,lcores[@cpus]>...] + + Lcore and CPU lists are grouped by ``(`` and ``)`` Within the group. + The ``-`` character is used as a range separator and ``,`` is used as a + single number separator. + The grouping ``()`` can be omitted for single element group. + The ``@`` can be omitted if cpus and lcores have the same value. + +.. Note:: + At a given instance only one core option ``--lcores``, ``-l`` or ``-c`` can + be used. + +* ``--master-lcore <core ID>`` + + Core ID that is used as master. + +* ``-s <service core mask>`` + + Hexadecimal bitmask of cores to be used as service cores. + +Device-related options +~~~~~~~~~~~~~~~~~~~~~~ + +* ``-b, --pci-blacklist <[domain:]bus:devid.func>`` + + Blacklist a PCI device to prevent EAL from using it. Multiple -b options are + allowed. + +.. Note:: + PCI blacklist cannot be used with ``-w`` option. + +* ``-w, --pci-whitelist <[domain:]bus:devid.func>`` + + Add a PCI device in white list. + +.. Note:: + PCI whitelist cannot be used with ``-b`` option. + +* ``--vdev <device arguments>`` + + Add a virtual device using the format:: + + <driver><id>[,key=val, ...] + + For example:: + + --vdev 'net_pcap0,rx_pcap=input.pcap,tx_pcap=output.pcap' + +* ``-d <path to shared object or directory>`` + + Load external drivers. An argument can be a single shared object file, or a + directory containing multiple driver shared objects. Multiple -d options are + allowed. + +* ``--no-pci`` + + Disable PCI bus. + +Multiprocessing-related options +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* ``--proc-type <primary|secondary|auto>`` + + Set the type of the current process. + +Memory-related options +~~~~~~~~~~~~~~~~~~~~~~ + +* ``-n <number of channels>`` + + Set the number of memory channels to use. + +* ``-r <number of ranks>`` + + Set the number of memory ranks (auto-detected by default). + +* ``-m <megabytes>`` + + Amount of memory to preallocate at startup. + +* ``--in-memory`` + + Do not create any shared data structures and run entirely in memory. Implies + ``--no-shconf`` and (if applicable) ``--huge-unlink``. + +* ``--iova-mode <pa|va>`` + + Force IOVA mode to a specific value. + +Debugging options +~~~~~~~~~~~~~~~~~ + +* ``--no-shconf`` + + No shared files created (implies no secondary process support). + +* ``--no-huge`` + + Use anonymous memory instead of hugepages (implies no secondary process + support). + +* ``--log-level <type:val>`` + + Specify log level for a specific component. For example:: + + --log-level eal:8 + + Can be specified multiple times. + +Other options +~~~~~~~~~~~~~ + +* ``-h``, ``--help`` + + Display help message listing all EAL parameters. + +* ``-v`` + + Display the version information on startup. + +* ``mbuf-pool-ops-name``: + + Pool ops name for mbuf to use. diff --git a/doc/guides/linux_gsg/index.rst b/doc/guides/linux_gsg/index.rst index 077f9302..0f9f6242 100644 --- a/doc/guides/linux_gsg/index.rst +++ b/doc/guides/linux_gsg/index.rst @@ -16,6 +16,7 @@ Getting Started Guide for Linux cross_build_dpdk_for_arm64 linux_drivers build_sample_apps + linux_eal_parameters enable_func quick_start nic_perf_intel_platform diff --git a/doc/guides/linux_gsg/linux_eal_parameters.rst b/doc/guides/linux_gsg/linux_eal_parameters.rst new file mode 100644 index 00000000..28aebfbd --- /dev/null +++ b/doc/guides/linux_gsg/linux_eal_parameters.rst @@ -0,0 +1,118 @@ +.. SPDX-License-Identifier: BSD-3-Clause + Copyright(c) 2018 Intel Corporation. + +EAL parameters +============== + +This document contains a list of all EAL parameters. These parameters can be +used by any DPDK application running on Linux. + +Common EAL parameters +--------------------- + +The following EAL parameters are common to all platforms supported by DPDK. + +.. include:: eal_args.include.rst + +Linux-specific EAL parameters +----------------------------- + +In addition to common EAL parameters, there are also Linux-specific EAL +parameters. + +Device-related options +~~~~~~~~~~~~~~~~~~~~~~ + +* ``--create-uio-dev`` + + Create ``/dev/uioX`` files for devices bound to igb_uio kernel driver + (usually done by the igb_uio driver itself). + +* ``--vmware-tsc-map`` + + Use VMware TSC map instead of native RDTSC. + +* ``--no-hpet`` + + Do not use the HPET timer. + +* ``--vfio-intr <legacy|msi|msix>`` + + Use specified interrupt mode for devices bound to VFIO kernel driver. + +Multiprocessing-related options +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* ``--file-prefix <prefix name>`` + + Use a different shared data file prefix for a DPDK process. This option + allows running multiple independent DPDK primary/secondary processes under + different prefixes. + +* ``--base-virtaddr <address>`` + + Attempt to use a different starting address for all memory maps of the + primary DPDK process. This can be helpful if secondary processes cannot + start due to conflicts in address map. + +Memory-related options +~~~~~~~~~~~~~~~~~~~~~~ + +* ``--legacy-mem`` + + Use legacy DPDK memory allocation mode. + +* ``--socket-mem <amounts of memory per socket>`` + + Preallocate specified amounts of memory per socket. The parameter is a + comma-separated list of values. For example:: + + --socket-mem 1024,2048 + + This will allocate 1 gigabyte of memory on socket 0, and 2048 megabytes of + memory on socket 1. + +* ``--socket-limit <amounts of memory per socket>`` + + Place a per-socket upper limit on memory use (non-legacy memory mode only). + 0 will disable the limit for a particular socket. + +* ``--single-file-segments`` + + Create fewer files in hugetlbfs (non-legacy mode only). + +* ``--huge-dir <path to hugetlbfs directory>`` + + Use specified hugetlbfs directory instead of autodetected ones. + +* ``--huge-unlink`` + + Unlink hugepage files after creating them (implies no secondary process + support). + +Other options +~~~~~~~~~~~~~ + +* ``--syslog <syslog facility>`` + + Set syslog facility. Valid syslog facilities are:: + + auth + cron + daemon + ftp + kern + lpr + mail + news + syslog + user + uucp + local0 + local1 + local2 + local3 + local4 + local5 + local6 + local7 diff --git a/doc/guides/linux_gsg/nic_perf_intel_platform.rst b/doc/guides/linux_gsg/nic_perf_intel_platform.rst index 987cd0a5..cf5c9e0d 100644 --- a/doc/guides/linux_gsg/nic_perf_intel_platform.rst +++ b/doc/guides/linux_gsg/nic_perf_intel_platform.rst @@ -64,7 +64,7 @@ This aligns with the previous output which showed that each channel has one memo Network Interface Card Requirements ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Use a `DPDK supported <http://dpdk.org/doc/nics>`_ high end NIC such as the Intel XL710 40GbE. +Use a `DPDK supported <http://core.dpdk.org/supported/>`_ high end NIC such as the Intel XL710 40GbE. Make sure each NIC has been flashed the latest version of NVM/firmware. diff --git a/doc/guides/nics/enic.rst b/doc/guides/nics/enic.rst index 746d8912..bc38f51a 100644 --- a/doc/guides/nics/enic.rst +++ b/doc/guides/nics/enic.rst @@ -14,7 +14,7 @@ How to obtain ENIC PMD integrated DPDK -------------------------------------- ENIC PMD support is integrated into the DPDK suite. dpdk-<version>.tar.gz -should be downloaded from http://dpdk.org +should be downloaded from http://core.dpdk.org/download/ Configuration information diff --git a/doc/guides/nics/index.rst b/doc/guides/nics/index.rst index bb107ae5..1e467050 100644 --- a/doc/guides/nics/index.rst +++ b/doc/guides/nics/index.rst @@ -51,23 +51,3 @@ Network Interface Controller Drivers vmxnet3 pcap_ring fail_safe - -**Figures** - -:numref:`figure_single_port_nic` :ref:`figure_single_port_nic` - -:numref:`figure_perf_benchmark` :ref:`figure_perf_benchmark` - -:numref:`figure_fast_pkt_proc` :ref:`figure_fast_pkt_proc` - -:numref:`figure_inter_vm_comms` :ref:`figure_inter_vm_comms` - -:numref:`figure_host_vm_comms` :ref:`figure_host_vm_comms` - -:numref:`figure_host_vm_comms_qemu` :ref:`figure_host_vm_comms_qemu` - -:numref:`figure_vmxnet3_int` :ref:`figure_vmxnet3_int` - -:numref:`figure_vswitch_vm` :ref:`figure_vswitch_vm` - -:numref:`figure_vm_vm_comms` :ref:`figure_vm_vm_comms` diff --git a/doc/guides/nics/mlx4.rst b/doc/guides/nics/mlx4.rst index 4a57c7a6..5326d916 100644 --- a/doc/guides/nics/mlx4.rst +++ b/doc/guides/nics/mlx4.rst @@ -213,7 +213,7 @@ Current RDMA core package and Linux kernel (recommended) Mellanox OFED as a fallback ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- `Mellanox OFED`_ version: **4.3, 4.4**. +- `Mellanox OFED`_ version: **4.4, 4.5**. - firmware version: **2.42.5000** and above. .. _`Mellanox OFED`: http://www.mellanox.com/page/products_dyn?product_family=26&mtag=linux_sw_drivers diff --git a/doc/guides/nics/mlx5.rst b/doc/guides/nics/mlx5.rst index 3610e008..23f0f570 100644 --- a/doc/guides/nics/mlx5.rst +++ b/doc/guides/nics/mlx5.rst @@ -142,6 +142,31 @@ Limitations To receive IPv6 Multicast messages on VM, explicitly set the relevant MAC address using rte_eth_dev_mac_addr_add() API. +- E-Switch VXLAN tunnel is not supported together with outer VLAN. + +- E-Switch Flows with VNI pattern must include the VXLAN decapsulation action. + +- E-Switch VXLAN decapsulation Flow: + + - can be appiled to PF port only. + - must specify VF port action (packet redirection from PF to VF). + - must specify tunnel outer UDP local (destination) port, wildcards not allowed. + - must specify tunnel outer VNI, wildcards not allowed. + - must specify tunnel outer local (destination) IPv4 or IPv6 address, wildcards not allowed. + - optionally may specify tunnel outer remote (source) IPv4 or IPv6, wildcards or group IPs allowed. + - optionally may specify tunnel inner source and destination MAC addresses. + +- E-Switch VXLAN encapsulation Flow: + + - can be applied to VF ports only. + - must specify PF port action (packet redirection from VF to PF). + - must specify the VXLAN item with tunnel outer parameters. + - must specify the tunnel outer VNI in the VXLAN item. + - must specify the tunnel outer remote (destination) UDP port in the VXLAN item. + - must specify the tunnel outer local (source) IPv4 or IPv6 in the , this address will locally (with scope link) assigned to the outer network interace, wildcards not allowed. + - must specify the tunnel outer remote (destination) IPv4 or IPv6 in the VXLAN item, group IPs allowed. + - must specify the tunnel outer destination MAC address in the VXLAN item, this address will be used to create neigh rule. + Statistics ---------- @@ -557,7 +582,7 @@ RMDA Core with Linux Kernel Mellanox OFED ^^^^^^^^^^^^^ -- Mellanox OFED version: **4.3, 4.4**. +- Mellanox OFED version: **4.4, 4.5**. - firmware version: - ConnectX-4: **12.21.1000** and above. diff --git a/doc/guides/nics/qede.rst b/doc/guides/nics/qede.rst index cba38868..c0a38338 100644 --- a/doc/guides/nics/qede.rst +++ b/doc/guides/nics/qede.rst @@ -58,9 +58,9 @@ Supported QLogic Adapters Prerequisites ------------- -- Requires storm firmware version **8.33.12.0**. Firmware may be available +- Requires storm firmware version **8.37.7.0**. Firmware may be available inbox in certain newer Linux distros under the standard directory - ``E.g. /lib/firmware/qed/qed_init_values-8.33.12.0.bin``. + ``E.g. /lib/firmware/qed/qed_init_values-8.37.7.0.bin``. If the required firmware files are not available then download it from `linux-firmware git repository <http://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/qed>`_ or `QLogic Driver Download Center <http://driverdownloads.qlogic.com/QLogicDriverDownloads_UI/DefaultNewSearch.aspx>`_. @@ -106,7 +106,7 @@ enabling debugging options may affect system performance. - ``CONFIG_RTE_LIBRTE_QEDE_FW`` (default **""**) Gives absolute path of firmware file. - ``Eg: "/lib/firmware/qed/qed_init_values-8.33.12.0.bin"`` + ``Eg: "/lib/firmware/qed/qed_init_values-8.37.7.0.bin"`` Empty string indicates driver will pick up the firmware file from the default location /lib/firmware/qed. CAUTION this option is more for custom firmware, it is not diff --git a/doc/guides/prog_guide/cryptodev_lib.rst b/doc/guides/prog_guide/cryptodev_lib.rst index 90d01e93..8ee33c87 100644 --- a/doc/guides/prog_guide/cryptodev_lib.rst +++ b/doc/guides/prog_guide/cryptodev_lib.rst @@ -1043,4 +1043,4 @@ Asymmetric Crypto Device API ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The cryptodev Library API is described in the -`DPDK API Reference <http://dpdk.org/doc/api/>`_ +`DPDK API Reference <http://doc.dpdk.org/api/>`_ diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/prog_guide/env_abstraction_layer.rst index 4f8612a2..8b5d050c 100644 --- a/doc/guides/prog_guide/env_abstraction_layer.rst +++ b/doc/guides/prog_guide/env_abstraction_layer.rst @@ -9,7 +9,7 @@ Environment Abstraction Layer The Environment Abstraction Layer (EAL) is responsible for gaining access to low-level resources such as hardware and memory space. It provides a generic interface that hides the environment specifics from the applications and libraries. It is the responsibility of the initialization routine to decide how to allocate these resources -(that is, memory space, PCI devices, timers, consoles, and so on). +(that is, memory space, devices, timers, consoles, and so on). Typical services expected from the EAL are: @@ -22,8 +22,6 @@ Typical services expected from the EAL are: * System Memory Reservation: The EAL facilitates the reservation of different memory zones, for example, physical memory areas for device interactions. -* PCI Address Abstraction: The EAL provides an interface to access PCI address space. - * Trace and Debug Functions: Logs, dump_stack, panic and so on. * Utility Functions: Spinlocks and atomic counters that are not provided in libc. @@ -39,8 +37,6 @@ EAL in a Linux-userland Execution Environment --------------------------------------------- In a Linux user space environment, the DPDK application runs as a user-space application using the pthread library. -PCI information about devices and address space is discovered through the /sys kernel interface and through kernel modules such as uio_pci_generic, or igb_uio. -Refer to the UIO: User-space drivers documentation in the Linux kernel. This memory is mmap'd in the application. The EAL performs physical memory allocation using mmap() in hugetlbfs (using huge page sizes to increase performance). This memory is exposed to DPDK service layers such as the :ref:`Mempool Library <Mempool_Library>`. @@ -250,15 +246,6 @@ The expected workflow is as follows: For more information, please refer to ``rte_malloc`` API documentation, specifically the ``rte_malloc_heap_*`` family of function calls. -PCI Access -~~~~~~~~~~ - -The EAL uses the /sys/bus/pci utilities provided by the kernel to scan the content on the PCI bus. -To access PCI memory, a kernel module called uio_pci_generic provides a /dev/uioX device file -and resource files in /sys -that can be mmap'd to obtain access to PCI address space from the application. -The DPDK-specific igb_uio module can also be used for this. Both drivers use the uio kernel feature (userland driver). - Per-lcore and Shared Variables ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/doc/guides/prog_guide/event_timer_adapter.rst b/doc/guides/prog_guide/event_timer_adapter.rst index 7bbbdfe9..3b4446ee 100644 --- a/doc/guides/prog_guide/event_timer_adapter.rst +++ b/doc/guides/prog_guide/event_timer_adapter.rst @@ -5,7 +5,7 @@ Event Timer Adapter Library =========================== The DPDK -`Event Device library <http://dpdk.org/doc/guides/prog_guide/eventdev.html>`_ +`Event Device library <http://doc.dpdk.org/guides/prog_guide/eventdev.html>`_ introduces an event driven programming model which presents applications with an alternative to the polling model traditionally used in DPDK applications. Event devices can be coupled with arbitrary components to provide @@ -21,7 +21,7 @@ The Event Timer Adapter library is designed to interface with hardware or software implementations of the timer mechanism; it will query an eventdev PMD to determine which implementation should be used. The default software implementation manages timers using the DPDK -`Timer library <http://dpdk.org/doc/guides/prog_guide/timer_lib.html>`_. +`Timer library <http://doc.dpdk.org/guides/prog_guide/timer_lib.html>`_. Examples of using the API are presented in the `API Overview`_ and `Processing Timer Expiry Events`_ sections. Code samples are abstracted and diff --git a/doc/guides/prog_guide/hash_lib.rst b/doc/guides/prog_guide/hash_lib.rst index f5beec1d..85a6edfa 100644 --- a/doc/guides/prog_guide/hash_lib.rst +++ b/doc/guides/prog_guide/hash_lib.rst @@ -14,55 +14,55 @@ For increased performance the DPDK Hash requires that all the keys have the same Hash API Overview ----------------- -The main configuration parameters for the hash are: +The main configuration parameters for the hash table are: -* Total number of hash entries +* Total number of hash entries in the table * Size of the key in bytes -* An extra flag used to describe additional settings, for example the multithreading mode of operation (as will be described later) +* An extra flag to describe additional settings, for example the multithreading mode of operation and extendable bucket functionality (as will be described later) -The hash also allows the configuration of some low-level implementation related parameters such as: +The hash table also allows the configuration of some low-level implementation related parameters such as: -* Hash function to translate the key into a bucket index +* Hash function to translate the key into a hash value -The main methods exported by the hash are: +The main methods exported by the Hash Library are: -* Add entry with key: The key is provided as input. If a new entry is successfully added to the hash for the specified key, - or there is already an entry in the hash for the specified key, then the position of the entry is returned. - If the operation was not successful, for example due to lack of free entries in the hash, then a negative value is returned; +* Add entry with key: The key is provided as input. If the new entry is successfully added to the hash table for the specified key, + or there is already an entry in the hash table for the specified key, then the position of the entry is returned. + If the operation was not successful, for example due to lack of free entries in the hash table, then a negative value is returned. * Delete entry with key: The key is provided as input. If an entry with the specified key is found in the hash, - then the entry is removed from the hash and the position where the entry was found in the hash is returned. - If no entry with the specified key exists in the hash, then a negative value is returned + then the entry is removed from the hash table and the position where the entry was found in the hash table is returned. + If no entry with the specified key exists in the hash table, then a negative value is returned -* 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. +* Lookup for entry with key: The key is provided as input. If an entry with the specified key is found in the hash table (i.e., lookup hit), + then the position of the entry is returned, otherwise (i.e., lookup miss) a negative value is returned. -Apart from these methods explained above, the API provides the user with few more options: +Apart from the basic methods explained above, the Hash Library API provides a few more advanced methods to query and update the hash table: -* 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. +* Add / lookup / delete entry 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 the hash value is already computed. -* Add / lookup with key and data: A pair of key-value is provided as input. This allows the user to store - not only the key, but also data which may be either a 8-byte integer or a pointer to external data (if data size is more than 8 bytes). +* Add / lookup entry with key and data: A data is provided as input for add. Add allows the user to store + not only the key, but also the data which may be either a 8-byte integer or a pointer to external data (if data size is more than 8 bytes). -* Combination of the two options above: User can provide key, precomputed hash and data. +* 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 +* Ability to not free the position of the entry in the hash table 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 +Also, the API contains a method to allow the user to look up entries in batches, 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. +with the current ones, which reduces significantly the performance overhead of the necessary memory accesses. The actual data associated with each key can be either managed by the user using a separate table that mirrors the hash in terms of number of entries and position of each entry, -as shown in the Flow Classification use case describes in the following sections, +as shown in the Flow Classification use case described in the following sections, or stored in the hash table itself. -The example hash tables in the L2/L3 Forwarding sample applications defines which port to forward a packet to based on a packet flow identified by the five-tuple lookup. +The example hash tables in the L2/L3 Forwarding sample applications define which port to forward a packet to based on a packet flow identified by the five-tuple lookup. However, this table could also be used for more sophisticated features and provide many other functions and actions that could be performed on the packets and flows. Multi-process support @@ -91,46 +91,53 @@ For concurrent writes, and concurrent reads and writes the following flag values 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, - 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). + the reader-writer lock will use hardware transactional memory (e.g., Intel® TSX) if supported to guarantee thread safety. 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. + For platforms (e.g., current ARM based platforms) that do not support transactional memory, it is advised to set this flag to achieve greater scalability in performance. + If this flag is set, the (RTE_HASH_EXTRA_FLAGS_NO_FREE_ON_DEL) flag is set by default. -* 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. +* If the 'do not free on delete' (RTE_HASH_EXTRA_FLAGS_NO_FREE_ON_DEL) flag is set, the position of the entry in the hash table is not freed upon calling delete(). This flag is enabled + by default when the lock free read/write concurrency flag 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 ----------------------- +Extendable Bucket Functionality support +---------------------------------------- +An extra flag is used to enable this functionality (flag is not set by default). When the (RTE_HASH_EXTRA_FLAGS_EXT_TABLE) is set and +in the very unlikely case due to excessive hash collisions that a key has failed to be inserted, the hash table bucket is extended with a linked +list to insert these failed keys. This feature is important for the workloads (e.g. telco workloads) that need to insert up to 100% of the +hash table size and can't tolerate any key insertion failure (even if very few). Currently the extendable bucket is not supported +with the lock-free concurrency implementation (RTE_HASH_EXTRA_FLAGS_RW_CONCURRENCY_LF). + + +Implementation Details (non Extendable Bucket Case) +--------------------------------------------------- The hash table has two main tables: -* First table is an array of entries which is further divided into buckets, - with the same number of consecutive array entries in each bucket. Each entry contains the computed primary - and secondary hashes of a given key (explained below), and an index to the second table. +* First table is an array of buckets each of which consists of multiple entries, + Each entry contains the signature + of a given key (explained below), and an index to the second table. * The second table is an array of all the keys stored in the hash table and its data associated to each key. -The hash library uses the cuckoo hash method to resolve collisions. +The hash library uses the Cuckoo Hash algorithm to resolve collisions. For any input key, there are two possible buckets (primary and secondary/alternative location) -where that key can be stored in the hash, therefore only the entries within those bucket need to be examined +to store that key in the hash table, therefore only the entries within those two buckets need to be examined when the key is looked up. -The lookup speed is achieved by reducing the number of entries to be scanned from the total -number of hash entries down to the number of entries in the two hash buckets, -as opposed to the basic method of linearly scanning all the entries in the array. -The hash uses a hash function (configurable) to translate the input key into a 4-byte key signature. -The bucket index is the key signature modulo the number of hash buckets. +The Hash Library uses a hash function (configurable) to translate the input key into a 4-byte hash value. +The bucket index and a 2-byte signature is derived from the hash value using partial-key hashing [partial-key]. -Once the buckets are identified, the scope of the hash add, -delete and lookup operations is reduced to the entries in those buckets (it is very likely that entries are in the primary bucket). +Once the buckets are identified, the scope of the key add, +delete, and lookup operations is reduced to the entries in those buckets (it is very likely that entries are in the primary bucket). -To speed up the search logic within the bucket, each hash entry stores the 4-byte key signature together with the full key for each hash entry. +To speed up the search logic within the bucket, each hash entry stores the 2-byte key signature together with the full key for each hash table entry. For large key sizes, comparing the input key against a key from the bucket can take significantly more time than -comparing the 4-byte signature of the input key against the signature of a key from the bucket. -Therefore, the signature comparison is done first and the full key comparison done only when the signatures matches. -The full key comparison is still necessary, as two input keys from the same bucket can still potentially have the same 4-byte hash signature, +comparing the 2-byte signature of the input key against the signature of a key from the bucket. +Therefore, the signature comparison is done first and the full key comparison is done only when the signatures matches. +The full key comparison is still necessary, as two input keys from the same bucket can still potentially have the same 2-byte signature, although this event is relatively rare for hash functions providing good uniform distributions for the set of input keys. Example of lookup: @@ -139,34 +146,51 @@ First of all, the primary bucket is identified and entry is likely to be stored If signature was stored there, we compare its key against the one provided and return the position where it was stored and/or the data associated to that key if there is a match. If signature is not in the primary bucket, the secondary bucket is looked up, where same procedure -is carried out. If there is no match there either, key is considered not to be in the table. +is carried out. If there is no match there either, key is not in the table and a negative value will be returned. Example of addition: -Like lookup, the primary and secondary buckets are identified. If there is an empty slot in -the primary bucket, primary and secondary signatures are stored in that slot, key and data (if any) are added to -the second table and an index to the position in the second table is stored in the slot of the first table. +Like lookup, the primary and secondary buckets are identified. If there is an empty entry in +the primary bucket, a signature is stored in that entry, key and data (if any) are added to +the second table and the index in the second table is stored in the entry of the first table. If there is no space in the primary bucket, one of the entries on that bucket is pushed to its alternative location, and the key to be added is inserted in its position. -To know where the alternative bucket of the evicted entry is, the secondary signature is looked up and alternative bucket index -is calculated from doing the modulo, as seen above. If there is room in the alternative bucket, the evicted entry -is stored in it. If not, same process is repeated (one of the entries gets pushed) until a non full bucket is found. +To know where the alternative bucket of the evicted entry is, a mechanism called partial-key hashing [partial-key] is used. +If there is room in the alternative bucket, the evicted entry +is stored in it. If not, same process is repeated (one of the entries gets pushed) until an empty entry is found. Notice that despite all the entry movement in the first table, the second table is not touched, which would impact greatly in performance. -In the very unlikely event that table enters in a loop where same entries are being evicted indefinitely, -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). +In the very unlikely event that an empty entry cannot be found after certain number of displacements, +key is considered not able to be added (unless extendable bucket flag is set, and in that case the bucket is extended to insert the key, as will be explained later). +With random keys, this method allows the user to get more than 90% table utilization, without +having to drop any stored entry (e.g. using a LRU replacement policy) or allocate more memory (extendable buckets or rehashing). 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 +Similar to lookup, the key is searched in its primary and secondary buckets. If the key is found, the +entry is marked as empty. 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 after readers are not referencing the position anymore. + +Implementation Details (with Extendable Bucket) +------------------------------------------------- +When the RTE_HASH_EXTRA_FLAGS_EXT_TABLE flag is set, the hash table implementation still uses the same Cuckoo Hash algorithm to store the keys into +the first and second tables. However, in the very unlikely event that a key can't be inserted after certain number of the Cuckoo displacements is +reached, the secondary bucket of this key is extended +with a linked list of extra buckets and the key is stored in this linked list. + +In case of lookup for a certain key, as before, the primary bucket is searched for a match and then the secondary bucket is looked up. +If there is no match there either, the extendable buckets (linked list of extra buckets) are searched one by one for a possible match and if there is no match +the key is considered not to be in the table. + +The deletion is the same as the case when the RTE_HASH_EXTRA_FLAGS_EXT_TABLE flag is not set. With one exception, if a key is deleted from any bucket +and an empty location is created, the last entry from the extendable buckets associated with this bucket is displaced into +this empty location to possibly shorten the linked list. + + Entry distribution in hash table -------------------------------- @@ -271,3 +295,4 @@ References ---------- * Donald E. Knuth, The Art of Computer Programming, Volume 3: Sorting and Searching (2nd Edition), 1998, Addison-Wesley Professional +* [partial-key] Bin Fan, David G. Andersen, and Michael Kaminsky, MemC3: compact and concurrent MemCache with dumber caching and smarter hashing, 2013, NSDI diff --git a/doc/guides/prog_guide/index.rst b/doc/guides/prog_guide/index.rst index 2086e244..ba8c1f6a 100644 --- a/doc/guides/prog_guide/index.rst +++ b/doc/guides/prog_guide/index.rst @@ -64,203 +64,3 @@ Programmer's Guide writing_efficient_code profile_app glossary - - -**Figures** - -:numref:`figure_architecture-overview` :ref:`figure_architecture-overview` - -:numref:`figure_linuxapp_launch` :ref:`figure_linuxapp_launch` - -:numref:`figure_malloc_heap` :ref:`figure_malloc_heap` - -:numref:`figure_ring1` :ref:`figure_ring1` - -:numref:`figure_ring-enqueue1` :ref:`figure_ring-enqueue1` - -:numref:`figure_ring-enqueue2` :ref:`figure_ring-enqueue2` - -:numref:`figure_ring-enqueue3` :ref:`figure_ring-enqueue3` - -:numref:`figure_ring-dequeue1` :ref:`figure_ring-dequeue1` - -:numref:`figure_ring-dequeue2` :ref:`figure_ring-dequeue2` - -:numref:`figure_ring-dequeue3` :ref:`figure_ring-dequeue3` - -:numref:`figure_ring-mp-enqueue1` :ref:`figure_ring-mp-enqueue1` - -:numref:`figure_ring-mp-enqueue2` :ref:`figure_ring-mp-enqueue2` - -:numref:`figure_ring-mp-enqueue3` :ref:`figure_ring-mp-enqueue3` - -:numref:`figure_ring-mp-enqueue4` :ref:`figure_ring-mp-enqueue4` - -:numref:`figure_ring-mp-enqueue5` :ref:`figure_ring-mp-enqueue5` - -:numref:`figure_ring-modulo1` :ref:`figure_ring-modulo1` - -:numref:`figure_ring-modulo2` :ref:`figure_ring-modulo2` - -:numref:`figure_memory-management` :ref:`figure_memory-management` - -:numref:`figure_memory-management2` :ref:`figure_memory-management2` - -:numref:`figure_mempool` :ref:`figure_mempool` - -:numref:`figure_mbuf1` :ref:`figure_mbuf1` - -:numref:`figure_mbuf2` :ref:`figure_mbuf2` - -:numref:`figure_multi_process_memory` :ref:`figure_multi_process_memory` - -:numref:`figure_kernel_nic_intf` :ref:`figure_kernel_nic_intf` - -:numref:`figure_pkt_flow_kni` :ref:`figure_pkt_flow_kni` - - -:numref:`figure_pkt_proc_pipeline_qos` :ref:`figure_pkt_proc_pipeline_qos` - -:numref:`figure_hier_sched_blk` :ref:`figure_hier_sched_blk` - -:numref:`figure_sched_hier_per_port` :ref:`figure_sched_hier_per_port` - -:numref:`figure_data_struct_per_port` :ref:`figure_data_struct_per_port` - -:numref:`figure_prefetch_pipeline` :ref:`figure_prefetch_pipeline` - -:numref:`figure_pipe_prefetch_sm` :ref:`figure_pipe_prefetch_sm` - -:numref:`figure_blk_diag_dropper` :ref:`figure_blk_diag_dropper` - -:numref:`figure_flow_tru_droppper` :ref:`figure_flow_tru_droppper` - -:numref:`figure_ex_data_flow_tru_dropper` :ref:`figure_ex_data_flow_tru_dropper` - -:numref:`figure_pkt_drop_probability` :ref:`figure_pkt_drop_probability` - -:numref:`figure_drop_probability_graph` :ref:`figure_drop_probability_graph` - -:numref:`figure_figure32` :ref:`figure_figure32` - -:numref:`figure_figure33` :ref:`figure_figure33` - -:numref:`figure_figure34` :ref:`figure_figure34` - -:numref:`figure_figure35` :ref:`figure_figure35` - -:numref:`figure_figure37` :ref:`figure_figure37` - -:numref:`figure_figure38` :ref:`figure_figure38` - -:numref:`figure_figure39` :ref:`figure_figure39` - -:numref:`figure_efd1` :ref:`figure_efd1` - -:numref:`figure_efd2` :ref:`figure_efd2` - -:numref:`figure_efd3` :ref:`figure_efd3` - -:numref:`figure_efd4` :ref:`figure_efd4` - -:numref:`figure_efd5` :ref:`figure_efd5` - -:numref:`figure_efd6` :ref:`figure_efd6` - -:numref:`figure_efd7` :ref:`figure_efd7` - -:numref:`figure_efd8` :ref:`figure_efd8` - -:numref:`figure_efd9` :ref:`figure_efd9` - -:numref:`figure_efd10` :ref:`figure_efd10` - -:numref:`figure_efd11` :ref:`figure_efd11` - -:numref:`figure_membership1` :ref:`figure_membership1` - -:numref:`figure_membership2` :ref:`figure_membership2` - -:numref:`figure_membership3` :ref:`figure_membership3` - -:numref:`figure_membership4` :ref:`figure_membership4` - -:numref:`figure_membership5` :ref:`figure_membership5` - -:numref:`figure_membership6` :ref:`figure_membership6` - -:numref:`figure_membership7` :ref:`figure_membership7` - -**Tables** - -:numref:`table_qos_1` :ref:`table_qos_1` - -:numref:`table_qos_2` :ref:`table_qos_2` - -:numref:`table_qos_3` :ref:`table_qos_3` - -:numref:`table_qos_4` :ref:`table_qos_4` - -:numref:`table_qos_5` :ref:`table_qos_5` - -:numref:`table_qos_6` :ref:`table_qos_6` - -:numref:`table_qos_7` :ref:`table_qos_7` - -:numref:`table_qos_8` :ref:`table_qos_8` - -:numref:`table_qos_9` :ref:`table_qos_9` - -:numref:`table_qos_10` :ref:`table_qos_10` - -:numref:`table_qos_11` :ref:`table_qos_11` - -:numref:`table_qos_12` :ref:`table_qos_12` - -:numref:`table_qos_13` :ref:`table_qos_13` - -:numref:`table_qos_14` :ref:`table_qos_14` - -:numref:`table_qos_15` :ref:`table_qos_15` - -:numref:`table_qos_16` :ref:`table_qos_16` - -:numref:`table_qos_17` :ref:`table_qos_17` - -:numref:`table_qos_18` :ref:`table_qos_18` - -:numref:`table_qos_19` :ref:`table_qos_19` - -:numref:`table_qos_20` :ref:`table_qos_20` - -:numref:`table_qos_21` :ref:`table_qos_21` - -:numref:`table_qos_22` :ref:`table_qos_22` - -:numref:`table_qos_23` :ref:`table_qos_23` - -:numref:`table_qos_24` :ref:`table_qos_24` - -:numref:`table_qos_25` :ref:`table_qos_25` - -:numref:`table_qos_26` :ref:`table_qos_26` - -:numref:`table_qos_27` :ref:`table_qos_27` - -:numref:`table_qos_28` :ref:`table_qos_28` - -:numref:`table_qos_29` :ref:`table_qos_29` - -:numref:`table_qos_30` :ref:`table_qos_30` - -:numref:`table_qos_31` :ref:`table_qos_31` - -:numref:`table_qos_32` :ref:`table_qos_32` - -:numref:`table_qos_33` :ref:`table_qos_33` - -:numref:`table_qos_34` :ref:`table_qos_34` - -:numref:`table_hash_lib_1` :ref:`table_hash_lib_1` - -:numref:`table_hash_lib_2` :ref:`table_hash_lib_2` diff --git a/doc/guides/prog_guide/switch_representation.rst b/doc/guides/prog_guide/switch_representation.rst index f5ee516f..e5c78c23 100644 --- a/doc/guides/prog_guide/switch_representation.rst +++ b/doc/guides/prog_guide/switch_representation.rst @@ -349,7 +349,7 @@ interconnection without introducing new concepts and whole new API to implement them. This is described in `flow API (rte_flow)`_. .. [6] `Generic flow API (rte_flow) - <http://dpdk.org/doc/guides/prog_guide/rte_flow.html>`_ + <http://doc.dpdk.org/guides/prog_guide/rte_flow.html>`_ Flow API (rte_flow) ------------------- @@ -737,7 +737,7 @@ Examples in subsequent sections apply to hypervisor applications only and are based on port representors **A**, **B** and **C**. .. [2] `Flow syntax - <http://dpdk.org/doc/guides/testpmd_app_ug/testpmd_funcs.html#flow-syntax>`_ + <http://doc.dpdk.org/guides/testpmd_app_ug/testpmd_funcs.html#flow-syntax>`_ Associating VF 1 with Physical Port 0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst index 34b28234..b48486d3 100644 --- a/doc/guides/rel_notes/deprecation.rst +++ b/doc/guides/rel_notes/deprecation.rst @@ -11,6 +11,20 @@ API and ABI deprecation notices are to be posted here. Deprecation Notices ------------------- +* linux: Linux kernel version 3.2 (which is the current minimum required + version for the DPDK) is not maintained anymore. Therefore the planned + minimum required kernel version for DPDK 19.02 will be the next oldest + Long Term Stable (LTS) version which is 3.16, but compatibility for + recent distribution kernels will be kept. + +* kvargs: The function ``rte_kvargs_process`` will get a new parameter + for returning key match count. It will ease handling of no-match case. + +* eal: function ``rte_bsf64`` in ``rte_bitmap.h`` has been renamed to + ``rte_bsf64_safe`` and moved to ``rte_common.h``. A new ``rte_bsf64`` function + will be added in the next release in ``rte_common.h`` that follows convention + set by existing ``rte_bsf32`` function. + * 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 @@ -29,11 +43,22 @@ Deprecation Notices - ``eal_parse_pci_DomBDF`` replaced by ``rte_pci_addr_parse`` - ``rte_eal_compare_pci_addr`` replaced by ``rte_pci_addr_cmp`` +* dpaa2: removal of ``rte_dpaa2_memsegs`` structure which has been replaced + by a pa-va search library. This structure was earlier being used for holding + memory segments used by dpaa2 driver for faster pa->va translation. This + structure would be made internal (or removed if all dependencies are cleared) + in future releases. + * mbuf: The opaque ``mbuf->hash.sched`` field will be updated to support generic definition in line with the ethdev TM and MTR APIs. Currently, this field is defined in librte_sched in a non-generic way. The new generic format will contain: queue ID, traffic class, color. Field size will not change. +* sched: Some API functions will change prototype due to the above + deprecation note for mbuf->hash.sched, e.g. ``rte_sched_port_pkt_write()`` + and ``rte_sched_port_pkt_read()`` will likely have an additional parameter + of type ``struct rte_sched_port``. + * mbuf: the macro ``RTE_MBUF_INDIRECT()`` will be removed in v18.08 or later and replaced with ``RTE_MBUF_CLONED()`` which is already added in v18.05. As ``EXT_ATTACHED_MBUF`` is newly introduced in v18.05, ``RTE_MBUF_INDIRECT()`` @@ -49,6 +74,31 @@ Deprecation Notices Target release for removal of the legacy API will be defined once most PMDs have switched to rte_flow. +* ethdev: Maximum and minimum MTU values vary between hardware devices. In + hardware agnostic DPDK applications access to such information would allow + a more accurate way of validating and setting supported MTU values on a per + device basis rather than using a defined default for all devices. To + resolve this, the following members will be added to ``rte_eth_dev_info``. + Note: these can be added to fit a hole in the existing structure for amd64 + but not for 32-bit, as such ABI change will occur as size of the structure + will increase. + + - Member ``uint16_t min_mtu`` the minimum MTU allowed. + - Member ``uint16_t max_mtu`` the maximum MTU allowed. + +* security: New field ``uint64_t opaque_data`` is planned to be added into + ``rte_security_session`` structure. That would allow upper layer to easily + associate/de-associate some user defined data with the security session. + +* cryptodev: several API and ABI changes are planned for rte_cryptodev + in v19.02: + + - The size and layout of ``rte_cryptodev_sym_session`` will change + to fix existing issues. + - The size and layout of ``rte_cryptodev_qp_conf`` and syntax of + ``rte_cryptodev_queue_pair_setup`` will change to to allow to use + two different mempools for crypto and device private sessions. + * pdump: As we changed to use generic IPC, some changes in APIs and structure are expected in subsequent release. diff --git a/doc/guides/rel_notes/known_issues.rst b/doc/guides/rel_notes/known_issues.rst index 95e4ce69..a1face9c 100644 --- a/doc/guides/rel_notes/known_issues.rst +++ b/doc/guides/rel_notes/known_issues.rst @@ -759,3 +759,70 @@ Netvsc driver and application restart **Driver/Module**: ``uio_hv_generic`` module. + + +PHY link up fails when rebinding i40e NICs to kernel driver +----------------------------------------------------------- + +**Description**: + Some kernel drivers are not able to handle the link status correctly + after DPDK application sets the PHY to link down. + +**Implication**: + The link status can't be set to "up" after the NIC is rebound to the + kernel driver. Before a DPDK application quits it will invoke the + function ``i40e_dev_stop()`` which will sets the PHY to link down. Some + kernel drivers may not be able to handle the link status correctly after + it retakes control of the device. This is a known PHY link configuration + issue in the i40e kernel driver. The fix has been addressed in the 2.7.4 rc + version. So if the i40e kernel driver is < 2.7.4 and doesn't have the + fix backported it will encounter this issue. + +**Resolution/Workaround**: + First try to remove and reinsert the i40e kernel driver. If that fails + reboot the system. + +**Affected Environment/Platform**: + All. + +**Driver/Module**: + Poll Mode Driver (PMD). + + +Restricted vdev ethdev operations supported in secondary process +---------------------------------------------------------------- +**Description** + In current virtual device sharing model, Ethernet device data structure will be + shared between primary and secondary process. Only those Ethernet device operations + which based on it are workable in secondary process. + +**Implication** + Some Ethernet device operations like device start/stop will be failed on virtual + device in secondary process. + +**Affected Environment/Platform**: + ALL. + +**Driver/Module**: + Virtual Device Poll Mode Driver (PMD). + + +Kernel crash when hot-unplug igb_uio device while DPDK application is running +----------------------------------------------------------------------------- + +**Description**: + When device has been bound to igb_uio driver and application is running, + hot-unplugging the device may cause kernel crash. + +**Reason**: + When device is hot-unplugged, igb_uio driver will be removed which will destroy UIO resources. + Later trying to access any uio resource will cause kernel crash. + +**Resolution/Workaround**: + If using DPDK for PCI HW hot-unplug, prefer to bind device with VFIO instead of IGB_UIO. + +**Affected Environment/Platform**: + ALL. + +**Driver/Module**: + ``igb_uio`` module. diff --git a/doc/guides/rel_notes/release_18_05.rst b/doc/guides/rel_notes/release_18_05.rst index 8dc22b01..3413d8de 100644 --- a/doc/guides/rel_notes/release_18_05.rst +++ b/doc/guides/rel_notes/release_18_05.rst @@ -594,7 +594,7 @@ Known Issues The issue is explained in more detail, including potential workarounds, in the Bugzilla entry referenced below. - Bugzilla entry: https://dpdk.org/tracker/show_bug.cgi?id=50 + Bugzilla entry: https://bugs.dpdk.org/show_bug.cgi?id=50 * **pdump is not compatible with old applications.** @@ -619,21 +619,21 @@ Known Issues needs to be run per-shell session, or before every test run. This change can also be made persistent by adding ``kern.coredump=0`` to ``/etc/sysctl.conf``. - Bugzilla entry: https://dpdk.org/tracker/show_bug.cgi?id=53 + Bugzilla entry: https://bugs.dpdk.org/show_bug.cgi?id=53 * **ixgbe PMD crash on hotplug detach when no VF created.** ixgbe PMD uninit path cause null pointer dereference because of port representor cleanup when number of VF is zero. - Bugzilla entry: https://dpdk.org/tracker/show_bug.cgi?id=57 + Bugzilla entry: https://bugs.dpdk.org/show_bug.cgi?id=57 * **Bonding PMD may fail to accept new slave ports in certain conditions.** In certain conditions when using testpmd, bonding may fail to register new slave ports. - Bugzilla entry: https://dpdk.org/tracker/show_bug.cgi?id=52. + Bugzilla entry: https://bugs.dpdk.org/show_bug.cgi?id=52. * **Unexpected performance regression in Vhost library.** @@ -641,7 +641,7 @@ Known Issues drop. However, in some setups, bigger performance drops have been measured when running micro-benchmarks. - Bugzilla entry: https://dpdk.org/tracker/show_bug.cgi?id=48 + Bugzilla entry: https://bugs.dpdk.org/show_bug.cgi?id=48 Shared Library Versions diff --git a/doc/guides/rel_notes/release_18_11.rst b/doc/guides/rel_notes/release_18_11.rst index 32ff0e5c..65bab557 100644 --- a/doc/guides/rel_notes/release_18_11.rst +++ b/doc/guides/rel_notes/release_18_11.rst @@ -48,7 +48,7 @@ New Features - eventdev (lib, PMDs) - etc * Other libs - * Apps, Examples, Tools (if significative) + * Apps, Examples, Tools (if significant) This section is a comment. Do not overwrite or remove it. Also, make sure to start the actual text at the margin. @@ -56,40 +56,42 @@ New Features * **Added support for using externally allocated memory in DPDK.** - DPDK has gained support for creating new ``rte_malloc`` heaps referencing + DPDK has added 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.** +* **Added check for ensuring allocated memory is addressable by devices.** Some devices can have addressing limitations so a new function, - ``rte_mem_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. + ``rte_mem_check_dma_mask()``, has been added for checking that allocated + memory is not out of the device range. Since memory can now be allocated + dynamically after initialization, a DMA mask is stored and any new allocated + memory will be checked against it and rejected if it is out of range. If + more than one device has addressing limitations, the DMA mask is the more + restrictive one. -* **Updated the C11 memory model version of ring library.** +* **Updated the C11 memory model version of the ring library.** - The latency is decreased for architectures using the C11 memory model - version of the ring library. + Added changes to decrease latency for architectures using the C11 memory + model version of the ring library. - On Cavium ThunderX2 platform, the changes decreased latency by 27~29% - and 3~15% for MPMC and SPSC cases respectively (with 2 lcores). The + On Cavium ThunderX2 platform, the changes decreased latency by 27-29% + and 3-15% for MPMC and SPSC cases respectively (with 2 lcores). The real improvements may vary with the number of contending lcores and - the size of ring. + the size of the ring. * **Added hot-unplug handle mechanism.** - ``rte_dev_hotplug_handle_enable`` and ``rte_dev_hotplug_handle_disable`` are - for enabling or disabling hotplug handle mechanism. + Added ``rte_dev_hotplug_handle_enable()`` and + ``rte_dev_hotplug_handle_disable()`` for enabling or disabling the hotplug + handle mechanism. -* **Support device multi-process hotplug.** +* **Added support for 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 support for hotplug and hot-unplug in a 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.** @@ -105,9 +107,10 @@ New Features 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** +* **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: + The Flow API support has been enhanced for the CXGBE Poll Mode Driver to + offload: * Match items: destination MAC address. * Action items: push/pop/rewrite vlan header, @@ -116,6 +119,7 @@ New Features 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. @@ -133,15 +137,33 @@ New Features * **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 the new enetc driver for the NXP enetc platform. See the + :doc:`../nics/enetc` NIC driver guide 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 + See the :doc:`../nics/atlantic` NIC driver guide for more details on this driver. +* **Updated mlx5 driver.** + + Updated the mlx5 driver including the following changes: + + * Improved security of PMD to prevent the NIC from getting stuck when + the application misbehaves. + * Reworked flow engine to supported e-switch flow rules (transfer attribute). + * Added support for header re-write(L2-L4), VXLAN encap/decap, count, match + on TCP flags and multiple flow groups with e-switch flow rules. + * Added support for match on metadata, VXLAN and MPLS encap/decap with flow + rules. + * Added support for ``RTE_ETH_DEV_CLOSE_REMOVE`` flag to provide better + support for representors. + * Added support for meson build. + * Fixed build issue with PPC. + * Added support for BlueField VF. + * Added support for externally allocated static memory for DMA. + * **Updated Solarflare network PMD.** Updated the sfc_efx driver including the following changes: @@ -156,36 +178,38 @@ New Features * Added AVX2-based vectorized Rx handler. * Added VLAN and checksum offloads to the simple Tx handler. - * Added the count flow action. + * Added the "count" flow action. * Enabled the virtual address IOVA mode. -* **Updated failsafe driver.** +* **Updated the 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 support for Rx and Tx queues start and stop. + * Added support for Rx and Tx queues deferred start. + * Added support for runtime Rx and Tx queues setup. + * Added 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 +* **Added a devarg to use a PCAP interface physical MAC address.** + + A new devarg ``phy_mac`` was introduced to allow users to use the 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 support to allow a secondary process to 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.** +* **Added Crypto support to the Softnic PMD.** The Softnic is now capable of processing symmetric crypto workloads such - as cipher, cipher-authentication chaining, and aead encryption and + as cipher, cipher-authentication chaining, and AEAD encryption and decryption. This is achieved by calling DPDK Cryptodev APIs. * **Added cryptodev port to port library.** @@ -195,30 +219,30 @@ New Features * **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. + In the pipeline library support was added for symmetric crypto action + parsing and an action handler was implemented. The action allows automatic + preparation of 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 .** +* **Updated the AESNI MB PMD.** - Added support for the third generation of Intel QuickAssist devices. + The AESNI MB PMD has been updated with additional support for the AES-GCM + algorithm. -* **Updated the QAT PMD.** +* **Added NXP CAAM JR PMD.** - The QAT PMD was updated with additional support for: + Added the new caam job ring driver for NXP platforms. See the + :doc:`../cryptodevs/caam_jr` guide for more details on this new driver. - * AES-CMAC algorithm. +* **Added support for GEN3 devices to Intel QAT driver.** -* **Updated the AESNI MB PMD.** + Added support for the third generation of Intel QuickAssist devices. - The AESNI MB PMD has been updated with additional support for AES-GCM - algorithm support. +* **Updated the QAT PMD.** -* **Added NXP CAAM JR PMD.** + The QAT PMD was updated with additional support for: - 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. + * The AES-CMAC algorithm. * **Added support for Dynamic Huffman Encoding to Intel QAT comp PMD.** @@ -227,7 +251,7 @@ New Features * **Added Event Ethernet Tx Adapter.** - Added event ethernet Tx adapter library that provides configuration and + 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 @@ -243,23 +267,23 @@ New Features * **Added extendable bucket feature to hash library (rte_hash).** - This new “extendable bucket” feature provides 100% insertion guarantee to + 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 + 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. + blocked due to a preempted writer thread. This allows the hash library + to be used in scenarios where the writer thread runs on the control plane. -* **Added Traffic Pattern Aware Power Control Library** +* **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 + Added an experimental library that extends the Power Library and provides + empty_poll APIs. This feature measures how many times empty_polls are + executed per core and uses the number of empty polls as a hint for system power management. See the :doc:`../prog_guide/power_man` section of the DPDK Programmers @@ -275,27 +299,27 @@ New Features * **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 + Added a new telemetry API which allows applications to transparently expose + their telemetry in JSON via a UNIX socket. The JSON can be consumed by any Service Assurance agent, such as CollectD. * **Updated KNI kernel module, rte_kni library, and KNI sample application.** Updated the KNI kernel module with a new kernel module parameter, ``carrier=[on|off]`` to allow the user to control the default carrier - state of KNI kernel network interfaces. The default carrier state + state of the KNI kernel network interfaces. The default carrier state is now set to ``off``, so the interfaces cannot be used until the carrier state is set to ``on`` via ``rte_kni_update_link`` or by writing ``1`` to ``/sys/devices/virtual/net/<iface>/carrier``. In previous versions the default carrier state was left undefined. See :doc:`../prog_guide/kernel_nic_interface` for more information. - Added the new API function ``rte_kni_update_link`` to allow the user + Also added the new API function ``rte_kni_update_link()`` to allow the user to set the carrier state of the KNI kernel network interface. - Added a new command line flag ``-m`` to the KNI sample application to + Also added a new command line flag ``-m`` to the KNI sample application to monitor and automatically reflect the physical NIC carrier state to the - KNI kernel network interface with the new ``rte_kni_update_link`` API. + KNI kernel network interface with the new ``rte_kni_update_link()`` API. See :doc:`../sample_app_ug/kernel_nic_interface` for more information. * **Added ability to switch queue deferred start flag on testpmd app.** @@ -305,7 +329,7 @@ New Features the specified port. The port must be stopped before the command call in order to reconfigure queues. -* **Add a new sample for vDPA** +* **Add a new sample application for vDPA.** The vdpa sample application creates vhost-user sockets by using the vDPA backend. vDPA stands for vhost Data Path Acceleration which utilizes @@ -320,12 +344,12 @@ New Features computation to the NIST Cryptographic Algorithm Validation Program (CAVP) test vectors. -* **Allow unit test binary to take parameters from the environment** +* **Allow unit test binary to take parameters from the environment.** The unit test "test", or "dpdk-test", binary is often called from scripts, - which can make passing additional parameters, such as a coremask, to it more - awkward. Support has been added to the application to allow it to take - additional command-line parameter values from the "DPDK_TEST_PARAMS" + which can make passing additional parameters, such as a coremask, + difficult. Support has been added to the application to allow it to take + additional command-line parameter values from the ``DPDK_TEST_PARAMS`` environment variable to make this application easier to use. @@ -347,13 +371,14 @@ API Changes 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. + + In addition the ``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: @@ -370,8 +395,8 @@ API Changes ``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 + and ``rte_eal_hotplug_remove()``/``rte_dev_remove()`` has been extended. + In the 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()`` @@ -379,42 +404,43 @@ API Changes ``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``. + ``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. + This new behavior 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 +* 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. +* The default behavior of CRC strip offload has changed in this + release. Without any specific Rx offload flag, default behavior by a 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. +* eventdev: The type of the second parameter to + ``rte_event_eth_rx_adapter_caps_get()`` has been changed from uint8_t to + uint16_t. * kni: By default, interface carrier status is ``off`` which means there won't - be any traffic. It can be set to ``on`` via ``rte_kni_update_link()`` API - or via ``sysfs`` interface: - ``echo 1 > /sys/class/net/vEth0/carrier``. + be any traffic. It can be set to ``on`` via ``rte_kni_update_link()`` API or + via ``sysfs`` interface: ``echo 1 > /sys/class/net/vEth0/carrier``. + Note interface should be ``up`` to be able to read/write sysfs interface. When KNI sample application is used, ``-m`` parameter can be used to automatically update the carrier status for the interface. -* kni: When ethtool support enabled (``CONFIG_RTE_KNI_KMOD_ETHTOOL=y``) - ethtool commands ``ETHTOOL_GSET & ETHTOOL_SSET`` are no more supported for the - kernels that has ``ETHTOOL_GLINKSETTINGS & ETHTOOL_SLINKSETTINGS`` support. +* kni: When ethtool support is enabled (``CONFIG_RTE_KNI_KMOD_ETHTOOL=y``) + ethtool commands ``ETHTOOL_GSET & ETHTOOL_SSET`` are no longer supported for + kernels that have ``ETHTOOL_GLINKSETTINGS & ETHTOOL_SLINKSETTINGS`` support. This means ``ethtool "-a|--show-pause", "-s|--change"`` won't work, and ``ethtool <iface>`` output will have less information. @@ -434,42 +460,30 @@ ABI Changes ========================================================= * 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. + ``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. + supporting external memory in DPDK: -* 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. + - 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 the most + restrictive DMA mask based on the devices addressing limitations. -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. - ========================================================= +* eal: The structure ``rte_device`` has a new field to reference a + ``rte_bus``. It thus changes the size of the ``struct rte_device`` and the + inherited device structures of all buses. Shared Library Versions @@ -561,11 +575,24 @@ Known Issues 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. +* 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. + +* IBM Power8 is not supported in this release of DPDK. IBM Power9 is + supported. -* IBM Power8 is not supported by this release of DPDK. IBM Power9 is supported. +* ``AVX-512`` support has been disabled for ``GCC`` builds [1] because of a + crash [2]. This can affect ``native`` machine type build targets on the + platforms that support ``AVX512F`` like ``Intel Skylake`` processors, and + can cause a possible performance drop. The immediate workaround is to use + ``clang`` compiler on these platforms. The issue has been identified as a + GCC defect and reported to the GCC community [3]. Further actions will be + taken based on the GCC defect result. + + - [1]: Commit 8d07c82b239f ("mk: disable gcc AVX512F support") + - [2]: https://bugs.dpdk.org/show_bug.cgi?id=97 + - [3]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88096 Tested Platforms @@ -586,3 +613,251 @@ Tested Platforms This section is a comment. Do not overwrite or remove it. Also, make sure to start the actual text at the margin. ========================================================= + +* Intel(R) platforms with Intel(R) NICs combinations + + * CPU + + * Intel(R) Atom(TM) CPU C3758 @ 2.20GHz + * Intel(R) Xeon(R) CPU D-1541 @ 2.10GHz + * Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz + * Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz + * Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz + * Intel(R) Xeon(R) Platinum 8180 CPU @ 2.50GHz + + * OS: + + * CentOS 7.5 + * Fedora 25 + * Fedora 28 + * FreeBSD 11.2 + * Red Hat Enterprise Linux Server release 7.5 + * Open SUSE 15 + * Wind River Linux 8 + * Ubuntu 14.04 + * Ubuntu 16.04 + * Ubuntu 16.10 + * Ubuntu 17.10 + * Ubuntu 18.04 + + * NICs: + + * Intel(R) 82599ES 10 Gigabit Ethernet Controller + + * Firmware version: 0x61bf0001 + * Device id (pf/vf): 8086:10fb / 8086:10ed + * Driver version: 5.2.3 (ixgbe) + + * Intel(R) Corporation Ethernet Connection X552/X557-AT 10GBASE-T + + * Firmware version: 0x800003e7 + * Device id (pf/vf): 8086:15ad / 8086:15a8 + * Driver version: 4.4.6 (ixgbe) + + * Intel(R) Ethernet Converged Network Adapter X710-DA4 (4x10G) + + * Firmware version: 6.01 0x80003221 + * Device id (pf/vf): 8086:1572 / 8086:154c + * Driver version: 2.4.6 (i40e) + + * Intel(R) Corporation Ethernet Connection X722 for 10GbE SFP+ (4x10G) + + * Firmware version: 3.33 0x80000fd5 0.0.0 + * Device id (pf/vf): 8086:37d0 / 8086:37cd + * Driver version: 2.4.6 (i40e) + + * Intel(R) Ethernet Converged Network Adapter XXV710-DA2 (2x25G) + + * Firmware version: 6.01 0x80003221 + * Device id (pf/vf): 8086:158b / 8086:154c + * Driver version: 2.4.6 (i40e) + + * Intel(R) Ethernet Converged Network Adapter XL710-QDA2 (2X40G) + + * Firmware version: 6.01 0x8000321c + * Device id (pf/vf): 8086:1583 / 8086:154c + * Driver version: 2.4.6 (i40e) + + * Intel(R) Corporation I350 Gigabit Network Connection + + * Firmware version: 1.63, 0x80000dda + * Device id (pf/vf): 8086:1521 / 8086:1520 + * Driver version: 5.4.0-k (igb) + +* Intel(R) platforms with Mellanox(R) NICs combinations + + * CPU: + + * Intel(R) Xeon(R) Gold 6154 CPU @ 3.00GHz + * Intel(R) Xeon(R) CPU E5-2697A v4 @ 2.60GHz + * Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz + * Intel(R) Xeon(R) CPU E5-2680 v2 @ 2.80GHz + * Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz + * Intel(R) Xeon(R) CPU E5-2640 @ 2.50GHz + * Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz + + * OS: + + * Red Hat Enterprise Linux Server release 7.6 (Maipo) + * Red Hat Enterprise Linux Server release 7.5 (Maipo) + * Red Hat Enterprise Linux Server release 7.4 (Maipo) + * Red Hat Enterprise Linux Server release 7.3 (Maipo) + * Red Hat Enterprise Linux Server release 7.2 (Maipo) + * Ubuntu 18.10 + * Ubuntu 18.04 + * Ubuntu 17.10 + * Ubuntu 16.04 + * SUSE Linux Enterprise Server 15 + + * MLNX_OFED: 4.4-2.0.1.0 + * MLNX_OFED: 4.5-0.3.1.0 + + * NICs: + + * Mellanox(R) ConnectX(R)-3 Pro 40G MCX354A-FCC_Ax (2x40G) + + * Host interface: PCI Express 3.0 x8 + * Device ID: 15b3:1007 + * Firmware version: 2.42.5000 + + * Mellanox(R) ConnectX(R)-4 10G MCX4111A-XCAT (1x10G) + + * Host interface: PCI Express 3.0 x8 + * Device ID: 15b3:1013 + * Firmware version: 12.23.8022 and above + + * Mellanox(R) ConnectX(R)-4 10G MCX4121A-XCAT (2x10G) + + * Host interface: PCI Express 3.0 x8 + * Device ID: 15b3:1013 + * Firmware version: 12.23.8022 and above + + * Mellanox(R) ConnectX(R)-4 25G MCX4111A-ACAT (1x25G) + + * Host interface: PCI Express 3.0 x8 + * Device ID: 15b3:1013 + * Firmware version: 12.23.8022 and above + + * Mellanox(R) ConnectX(R)-4 25G MCX4121A-ACAT (2x25G) + + * Host interface: PCI Express 3.0 x8 + * Device ID: 15b3:1013 + * Firmware version: 12.23.8022 and above + + * Mellanox(R) ConnectX(R)-4 40G MCX4131A-BCAT/MCX413A-BCAT (1x40G) + + * Host interface: PCI Express 3.0 x8 + * Device ID: 15b3:1013 + * Firmware version: 12.23.8022 and above + + * Mellanox(R) ConnectX(R)-4 40G MCX415A-BCAT (1x40G) + + * Host interface: PCI Express 3.0 x16 + * Device ID: 15b3:1013 + * Firmware version: 12.23.8022 and above + + * Mellanox(R) ConnectX(R)-4 50G MCX4131A-GCAT/MCX413A-GCAT (1x50G) + + * Host interface: PCI Express 3.0 x8 + * Device ID: 15b3:1013 + * Firmware version: 12.23.8022 and above + + * Mellanox(R) ConnectX(R)-4 50G MCX414A-BCAT (2x50G) + + * Host interface: PCI Express 3.0 x8 + * Device ID: 15b3:1013 + * Firmware version: 12.23.8022 and above + + * Mellanox(R) ConnectX(R)-4 50G MCX415A-GCAT/MCX416A-BCAT/MCX416A-GCAT (2x50G) + + * Host interface: PCI Express 3.0 x16 + * Device ID: 15b3:1013 + * Firmware version: 12.23.8022 and above + * Firmware version: 12.23.8022 and above + + * Mellanox(R) ConnectX(R)-4 50G MCX415A-CCAT (1x100G) + + * Host interface: PCI Express 3.0 x16 + * Device ID: 15b3:1013 + * Firmware version: 12.23.8022 and above + + * Mellanox(R) ConnectX(R)-4 100G MCX416A-CCAT (2x100G) + + * Host interface: PCI Express 3.0 x16 + * Device ID: 15b3:1013 + * Firmware version: 12.23.8022 and above + + * Mellanox(R) ConnectX(R)-4 Lx 10G MCX4121A-XCAT (2x10G) + + * Host interface: PCI Express 3.0 x8 + * Device ID: 15b3:1015 + * Firmware version: 14.23.8022 and above + + * Mellanox(R) ConnectX(R)-4 Lx 25G MCX4121A-ACAT (2x25G) + + * Host interface: PCI Express 3.0 x8 + * Device ID: 15b3:1015 + * Firmware version: 14.23.8022 and above + + * Mellanox(R) ConnectX(R)-5 100G MCX556A-ECAT (2x100G) + + * Host interface: PCI Express 3.0 x16 + * Device ID: 15b3:1017 + * Firmware version: 16.23.8022 and above + + * Mellanox(R) ConnectX(R)-5 Ex EN 100G MCX516A-CDAT (2x100G) + + * Host interface: PCI Express 4.0 x16 + * Device ID: 15b3:1019 + * Firmware version: 16.23.8022 and above + +* ARM platforms with Mellanox(R) NICs combinations + + * CPU: + + * Qualcomm ARM 1.1 2500MHz + + * OS: + + * Red Hat Enterprise Linux Server release 7.5 (Maipo) + + * NICs: + + * Mellanox(R) ConnectX(R)-4 Lx 25G MCX4121A-ACAT (2x25G) + + * Host interface: PCI Express 3.0 x8 + * Device ID: 15b3:1015 + * Firmware version: 14.24.0220 + + * Mellanox(R) ConnectX(R)-5 100G MCX556A-ECAT (2x100G) + + * Host interface: PCI Express 3.0 x16 + * Device ID: 15b3:1017 + * Firmware version: 16.24.0220 + +* Mellanox(R) BlueField SmartNIC + + * Mellanox(R) BlueField SmartNIC MT416842 (2x25G) + + * Host interface: PCI Express 3.0 x16 + * Device ID: 15b3:a2d2 + * Firmware version: 18.24.0246 + + * SoC ARM cores running OS: + + * CentOS Linux release 7.4.1708 (AltArch) + * MLNX_OFED 4.4-2.5.3.0 + + * DPDK application running on ARM cores inside SmartNIC + +* ARM SoC combinations from NXP (with integrated NICs) + + * SoC: + + * NXP/Freescale QorIQ LS1046A with ARM Cortex A72 + * NXP/Freescale QorIQ LS2088A with ARM Cortex A72 + + * OS: + + * Ubuntu 18.04.1 LTS with NXP QorIQ LSDK 1809 support packages + * Ubuntu 16.04.3 LTS with NXP QorIQ LSDK 1803 support packages diff --git a/doc/guides/sample_app_ug/index.rst b/doc/guides/sample_app_ug/index.rst index b2455e09..2945be08 100644 --- a/doc/guides/sample_app_ug/index.rst +++ b/doc/guides/sample_app_ug/index.rst @@ -58,63 +58,3 @@ Sample Applications User Guides fips_validation ipsec_secgw bbdev_app - -**Figures** - -:numref:`figure_exception_path_example` :ref:`figure_exception_path_example` - -:numref:`figure_kernel_nic` :ref:`figure_kernel_nic` - -:numref:`figure_l2_fwd_benchmark_setup_jobstats` :ref:`figure_l2_fwd_benchmark_setup_jobstats` - -:numref:`figure_l2_fwd_virtenv_benchmark_setup_jobstats` :ref:`figure_l2_fwd_virtenv_benchmark_setup_jobstats` - -:numref:`figure_l2_fwd_benchmark_setup` :ref:`figure_l2_fwd_benchmark_setup` - -:numref:`figure_l2_fwd_virtenv_benchmark_setup` :ref:`figure_l2_fwd_virtenv_benchmark_setup` - -:numref:`figure_l2_fwd_encrypt_flow` :ref:`figure_l2_fwd_encrypt_flow` - -:numref:`figure_ipv4_acl_rule` :ref:`figure_ipv4_acl_rule` - -:numref:`figure_example_rules` :ref:`figure_example_rules` - -:numref:`figure_load_bal_app_arch` :ref:`figure_load_bal_app_arch` - -:numref:`figure_sym_multi_proc_app` :ref:`figure_sym_multi_proc_app` - -:numref:`figure_client_svr_sym_multi_proc_app` :ref:`figure_client_svr_sym_multi_proc_app` - -:numref:`figure_qos_sched_app_arch` :ref:`figure_qos_sched_app_arch` - -:numref:`figure_pipeline_overview` :ref:`figure_pipeline_overview` - -:numref:`figure_ring_pipeline_perf_setup` :ref:`figure_ring_pipeline_perf_setup` - -:numref:`figure_threads_pipelines` :ref:`figure_threads_pipelines` - -:numref:`figure_vmdq_dcb_example` :ref:`figure_vmdq_dcb_example` - -:numref:`figure_test_pipeline_app` :ref:`figure_test_pipeline_app` - -:numref:`figure_dist_perf` :ref:`figure_dist_perf` - -:numref:`figure_dist_app` :ref:`figure_dist_app` - -:numref:`figure_vm_power_mgr_highlevel` :ref:`figure_vm_power_mgr_highlevel` - -:numref:`figure_vm_power_mgr_vm_request_seq` :ref:`figure_vm_power_mgr_vm_request_seq` -:numref:`figure_overlay_networking` :ref:`figure_overlay_networking` -:numref:`figure_tep_termination_arch` :ref:`figure_tep_termination_arch` - -:numref:`figure_ptpclient_highlevel` :ref:`figure_ptpclient_highlevel` - -:numref:`figure_efd_sample_app_overview` :ref:`figure_efd_sample_app_overview` - -**Tables** - -:numref:`table_qos_metering_1` :ref:`table_qos_metering_1` - -:numref:`table_qos_scheduler_1` :ref:`table_qos_scheduler_1` - -:numref:`table_test_pipeline_1` :ref:`table_test_pipeline_1` diff --git a/doc/guides/sample_app_ug/intro.rst b/doc/guides/sample_app_ug/intro.rst index 575995de..159bcf73 100644 --- a/doc/guides/sample_app_ug/intro.rst +++ b/doc/guides/sample_app_ug/intro.rst @@ -10,6 +10,16 @@ DPDK features. Users interested in getting started with DPDK can take the applications, try out the features, and then extend them to fit their needs. +Running Sample Applications +--------------------------- + +Some sample applications may have their own command-line parameters described in +their respective guides, however all of them also share the same EAL parameters. +Please refer to :doc:`../linux_gsg/linux_eal_parameters` or +:doc:`../freebsd_gsg/freebsd_eal_parameters` for a list of available EAL +command-line options. + + The DPDK Sample Applications ---------------------------- diff --git a/doc/guides/sample_app_ug/vhost_crypto.rst b/doc/guides/sample_app_ug/vhost_crypto.rst index 3db57eab..bbc25bde 100644 --- a/doc/guides/sample_app_ug/vhost_crypto.rst +++ b/doc/guides/sample_app_ug/vhost_crypto.rst @@ -30,7 +30,7 @@ Start the vhost_crypto example ./vhost_crypto [EAL options] -- --config (lcore,cdev-id,queue-id)[,(lcore,cdev-id,queue-id)] - --socketfile lcore,PATH + --socket-file lcore,PATH [--zero-copy] [--guest-polling] diff --git a/doc/guides/testpmd_app_ug/run_app.rst b/doc/guides/testpmd_app_ug/run_app.rst index c79fd0d0..f717bd3f 100644 --- a/doc/guides/testpmd_app_ug/run_app.rst +++ b/doc/guides/testpmd_app_ug/run_app.rst @@ -7,135 +7,9 @@ Running the Application EAL Command-line Options ------------------------ -The following are the EAL command-line options that can be used in conjunction with the testpmd, -or any other DPDK application. -See the DPDK Getting Started Guides for more information on these options. - -* ``-c COREMASK`` - - Set the hexadecimal bitmask of the cores to run on. - -* ``-l CORELIST`` - - List of cores to run on - - The argument format is ``<c1>[-c2][,c3[-c4],...]`` - where ``c1``, ``c2``, etc are core indexes between 0 and 128. - -* ``--lcores COREMAP`` - - Map lcore set to physical cpu set - - The argument format is:: - - <lcores[@cpus]>[<,lcores[@cpus]>...] - - Lcore and CPU lists are grouped by ``(`` and ``)`` Within the group. - The ``-`` character is used as a range separator and ``,`` is used as a single number separator. - The grouping ``()`` can be omitted for single element group. - The ``@`` can be omitted if cpus and lcores have the same value. - -.. Note:: - At a given instance only one core option ``--lcores``, ``-l`` or ``-c`` can be used. - - -* ``--master-lcore ID`` - - Core ID that is used as master. - -* ``-n NUM`` - - Set the number of memory channels to use. - -* ``-b, --pci-blacklist domain:bus:devid.func`` - - Blacklist a PCI device to prevent EAL from using it. Multiple -b options are allowed. - -* ``-d LIB.so`` - - Load an external driver. Multiple -d options are allowed. - -* ``-w, --pci-whitelist domain:bus:devid:func`` - - Add a PCI device in white list. - -* ``-m MB`` - - Memory to allocate. See also ``--socket-mem``. - -* ``-r NUM`` - - Set the number of memory ranks (auto-detected by default). - -* ``-v`` - - Display the version information on startup. - -* ``--syslog`` - - Set the syslog facility. - -* ``--socket-mem`` - - Set the memory to allocate on specific sockets (use comma separated values). - -* ``--huge-dir`` - - Specify the directory where the hugetlbfs is mounted. - -* ``mbuf-pool-ops-name``: - - Pool ops name for mbuf to use. - -* ``--proc-type`` - - Set the type of the current process. - -* ``--file-prefix`` - - Prefix for hugepage filenames. - -* ``-vmware-tsc-map`` - - Use VMware TSC map instead of native RDTSC. - -* ``--vdev`` - - Add a virtual device using the format:: - - <driver><id>[,key=val, ...] - - For example:: - - --vdev 'net_pcap0,rx_pcap=input.pcap,tx_pcap=output.pcap' - -* ``--base-virtaddr`` - - Specify base virtual address. - -* ``--create-uio-dev`` - - Create ``/dev/uioX`` (usually done by hotplug). - -* ``--no-shconf`` - - No shared config (mmap-ed files). - -* ``--no-pci`` - - Disable pci. - -* ``--no-hpet`` - - Disable hpet. - -* ``--no-huge`` - - Use malloc instead of hugetlbfs. - -* ``--iova-mode <pa|va>`` - - Force IOVA mode to a specific value. +Please refer to :doc:`../linux_gsg/linux_eal_parameters` or +:doc:`../freebsd_gsg/freebsd_eal_parameters` for a list of available EAL +command-line options. Testpmd Command-line Options diff --git a/doc/guides/tools/pdump.rst b/doc/guides/tools/pdump.rst index 5168c81a..7c2b73e7 100644 --- a/doc/guides/tools/pdump.rst +++ b/doc/guides/tools/pdump.rst @@ -42,8 +42,6 @@ The tool has a number of command line options: [ring-size=<ring size>], [mbuf-size=<mbuf data size>], [total-num-mbufs=<number of mbufs>]' - [--server-socket-path=<server socket dir>] - [--client-socket-path=<client socket dir>] The ``--pdump`` command line option is mandatory and it takes various sub arguments which are described in below section. @@ -56,14 +54,6 @@ below section. * Multiple instances of ``--pdump`` can be passed to capture packets on different port and queue combinations. -The ``--server-socket-path`` command line option is optional. This represents the server socket directory. -If no value is passed default values are used i.e. ``/var/run/.dpdk/`` for root users and ``~/.dpdk/`` -for non root users. - -The ``--client-socket-path`` command line option is optional. This represents the client socket directory. -If no value is passed default values are used i.e. ``/var/run/.dpdk/`` for root users and ``~/.dpdk/`` -for non root users. - The ``--pdump`` parameters ~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/doc/guides/tools/testbbdev.rst b/doc/guides/tools/testbbdev.rst index 234a64f5..5caa9023 100644 --- a/doc/guides/tools/testbbdev.rst +++ b/doc/guides/tools/testbbdev.rst @@ -62,7 +62,8 @@ The following are the command-line options: ``-e EAL_PARAMS, --eal_params EAL_PARAMS`` Specifies EAL arguments which are passed to the test app. For more details, - refer to DPDK documentation at http://dpdk.org/doc. + refer to DPDK documentation at + http://doc.dpdk.org/guides/linux_gsg/linux_eal_parameters.html. ``-t TIMEOUT, --timeout TIMEOUT`` Specifies timeout in seconds. If not specified timeout is set to 300 seconds. |