-.. BSD LICENSE
- Copyright(c) 2015 Netronome Systems, Inc. All rights reserved.
+.. SPDX-License-Identifier: BSD-3-Clause
+ Copyright(c) 2015-2017 Netronome Systems, Inc. All rights reserved.
All rights reserved.
- Redistribution and use in source and binary forms, with or without
- modification, are permitted provided that the following conditions
- are met:
-
- * Redistributions of source code must retain the above copyright
- notice, this list of conditions and the following disclaimer.
- * Redistributions in binary form must reproduce the above copyright
- notice, this list of conditions and the following disclaimer in
- the documentation and/or other materials provided with the
- distribution.
- * Neither the name of Intel Corporation nor the names of its
- contributors may be used to endorse or promote products derived
- from this software without specific prior written permission.
-
- THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
- "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
- LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
- A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
- OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
- DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
- THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
- OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
NFP poll mode driver library
============================
Netronome's sixth generation of flow processors pack 216 programmable
cores and over 100 hardware accelerators that uniquely combine packet,
flow, security and content processing in a single device that scales
-up to 400 Gbps.
+up to 400-Gb/s.
This document explains how to use DPDK with the Netronome Poll Mode
Driver (PMD) supporting Netronome's Network Flow Processor 6xxx
-(NFP-6xxx).
+(NFP-6xxx) and Netronome's Flow Processor 4xxx (NFP-4xxx).
-Currently the driver supports virtual functions (VFs) only.
+NFP is a SRIOV capable device and the PMD supports the physical
+function (PF) and the virtual functions (VFs).
Dependencies
------------
-Before using the Netronome's DPDK PMD some NFP-6xxx configuration,
+Before using the Netronome's DPDK PMD some NFP configuration,
which is not related to DPDK, is required. The system requires
-installation of **Netronome's BSP (Board Support Package)** which includes
-Linux drivers, programs and libraries.
+installation of **Netronome's BSP (Board Support Package)** along
+with a specific NFP firmware application. Netronome's NSP ABI
+version should be 0.20 or higher.
-If you have a NFP-6xxx device you should already have the code and
-documentation for doing this configuration. Contact
+If you have a NFP device you should already have the code and
+documentation for this configuration. Contact
**support@netronome.com** to obtain the latest available firmware.
-The NFP Linux kernel drivers (including the required PF driver for the
-NFP) are available on Github at
-**https://github.com/Netronome/nfp-drv-kmods** along with build
+The NFP Linux netdev kernel driver for VFs has been a part of the
+vanilla kernel since kernel version 4.5, and support for the PF
+since kernel version 4.11. Support for older kernels can be obtained
+on Github at
+**https://github.com/Netronome/nfp-drv-kmods** along with the build
instructions.
-DPDK runs in userspace and PMDs uses the Linux kernel UIO interface to
-allow access to physical devices from userspace. The NFP PMD requires
-the **igb_uio** UIO driver, available with DPDK, to perform correct
-initialization.
+NFP PMD needs to be used along with UIO ``igb_uio`` or VFIO (``vfio-pci``)
+Linux kernel driver.
Building the software
---------------------
Netronome's PMD code is provided in the **drivers/net/nfp** directory.
Although NFP PMD has Netronome´s BSP dependencies, it is possible to
-compile it along with other DPDK PMDs even if no BSP was installed before.
+compile it along with other DPDK PMDs even if no BSP was installed previously.
Of course, a DPDK app will require such a BSP installed for using the
-NFP PMD.
-
-Default PMD configuration is at **common_linuxapp configuration** file:
-
-- **CONFIG_RTE_LIBRTE_NFP_PMD=y**
+NFP PMD, along with a specific NFP firmware application.
-Once DPDK is built all the DPDK apps and examples include support for
+Once the DPDK is built all the DPDK apps and examples include support for
the NFP PMD.
-System configuration
---------------------
-
-Using the NFP PMD is not different to using other PMDs. Usual steps are:
-
-#. **Configure hugepages:** All major Linux distributions have the hugepages
- functionality enabled by default. By default this allows the system uses for
- working with transparent hugepages. But in this case some hugepages need to
- be created/reserved for use with the DPDK through the hugetlbfs file system.
- First the virtual file system need to be mounted:
+Driver compilation and testing
+------------------------------
- .. code-block:: console
+Refer to the document :ref:`compiling and testing a PMD for a NIC <pmd_build_and_test>`
+for details.
- mount -t hugetlbfs none /mnt/hugetlbfs
+Using the PF
+------------
- The command uses the common mount point for this file system and it needs to
- be created if necessary.
+NFP PMD supports using the NFP PF as another DPDK port, but it does not
+have any functionality for controlling VFs. In fact, it is not possible to use
+the PMD with the VFs if the PF is being used by DPDK, that is, with the NFP PF
+bound to ``igb_uio`` or ``vfio-pci`` kernel drivers. Future DPDK versions will
+have a PMD able to work with the PF and VFs at the same time and with the PF
+implementing VF management along with other PF-only functionalities/offloads.
- Configuring hugepages is performed via sysfs:
+The PMD PF has extra work to do which will delay the DPDK app initialization
+like uploading the firmware and configure the Link state properly when starting or
+stopping a PF port. Since DPDK 18.05 the firmware upload happens when
+a PF is initialized, which was not always true with older DPDK versions.
- .. code-block:: console
+Depending on the Netronome product installed in the system, firmware files
+should be available under ``/lib/firmware/netronome``. DPDK PMD supporting the
+PF looks for a firmware file in this order:
- /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
+ 1) First try to find a firmware image specific for this device using the
+ NFP serial number:
- This sysfs file is used to specify the number of hugepages to reserve.
- For example:
+ serial-00-15-4d-12-20-65-10-ff.nffw
- .. code-block:: console
+ 2) Then try the PCI name:
- echo 1024 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
+ pci-0000:04:00.0.nffw
- This will reserve 2GB of memory using 1024 2MB hugepages. The file may be
- read to see if the operation was performed correctly:
+ 3) Finally try the card type and media:
- .. code-block:: console
+ nic_AMDA0099-0001_2x25.nffw
- cat /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
+Netronome's software packages install firmware files under ``/lib/firmware/netronome``
+to support all the Netronome's SmartNICs and different firmware applications.
+This is usually done using file names based on SmartNIC type and media and with a
+directory per firmware application. Options 1 and 2 for firmware filenames allow
+more than one SmartNIC, same type of SmartNIC or different ones, and to upload a
+different firmware to each SmartNIC.
- The number of unused hugepages may also be inspected.
+ .. Note::
+ Currently the NFP PMD supports using the PF with Agilio Basic Firmware. See
+ https://help.netronome.com/support/solutions for more information on the
+ various firmwares supported by the Netronome Agilio CX smartNIC.
- Before executing the DPDK app it should match the value of nr_hugepages.
+PF multiport support
+--------------------
- .. code-block:: console
+The NFP PMD can work with up to 8 ports on the same PF device. The number of
+available ports is firmware and hardware dependent, and the driver looks for a
+firmware symbol during initialization to know how many can be used.
- cat /sys/kernel/mm/hugepages/hugepages-2048kB/free_hugepages
+DPDK apps work with ports, and a port is usually a PF or a VF PCI device.
+However, with the NFP PF multiport there is just one PF PCI device. Supporting
+this particular configuration requires the PMD to create ports in a special way,
+although once they are created, DPDK apps should be able to use them as normal
+PCI ports.
- The hugepages reservation should be performed at system initialization and
- it is usual to use a kernel parameter for configuration. If the reservation
- is attempted on a busy system it will likely fail. Reserving memory for
- hugepages may be done adding the following to the grub kernel command line:
+NFP ports belonging to same PF can be seen inside PMD initialization with a
+suffix added to the PCI ID: wwww:xx:yy.z_portn. For example, a PF with PCI ID
+0000:03:00.0 and four ports is seen by the PMD code as:
.. code-block:: console
- default_hugepagesz=1M hugepagesz=2M hugepages=1024
+ 0000:03:00.0_port0
+ 0000:03:00.0_port1
+ 0000:03:00.0_port2
+ 0000:03:00.0_port3
- This will reserve 2GBytes of memory using 2Mbytes huge pages.
+ .. Note::
- Finally, for a NUMA system the allocation needs to be made on the correct
- NUMA node. In a DPDK app there is a master core which will (usually) perform
- memory allocation. It is important that some of the hugepages are reserved
- on the NUMA memory node where the network device is attached. This is because
- of a restriction in DPDK by which TX and RX descriptors rings must be created
- on the master code.
+ There are some limitations with multiport support: RX interrupts and
+ device hot-plugging are not supported.
- Per-node allocation of hugepages may be inspected and controlled using sysfs.
- For example:
+PF multiprocess support
+-----------------------
- .. code-block:: console
+Due to how the driver needs to access the NFP through a CPP interface, which implies
+to use specific registers inside the chip, the number of secondary processes with PF
+ports is limited to only one.
- cat /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
+This limitation will be solved in future versions but having basic multiprocess support
+is important for allowing development and debugging through the PF using a secondary
+process which will create a CPP bridge for user space tools accessing the NFP.
- For a NUMA system there will be a specific hugepage directory per node
- allowing control of hugepage reservation. A common problem may occur when
- hugepages reservation is performed after the system has been working for
- some time. Configuration using the global sysfs hugepage interface will
- succeed but the per-node allocations may be unsatisfactory.
- The number of hugepages that need to be reserved depends on how the app uses
- TX and RX descriptors, and packets mbufs.
+System configuration
+--------------------
-#. **Enable SR-IOV on the NFP-6xxx device:** The current NFP PMD works with
- Virtual Functions (VFs) on a NFP device. Make sure that one of the Physical
- Function (PF) drivers from the above Github repository is installed and
- loaded.
+#. **Enable SR-IOV on the NFP device:** The current NFP PMD supports the PF and
+ the VFs on a NFP device. However, it is not possible to work with both at the
+ same time because the VFs require the PF being bound to the NFP PF Linux
+ netdev driver. Make sure you are working with a kernel with NFP PF support or
+ get the drivers from the above Github repository and follow the instructions
+ for building and installing it.
- Virtual Functions need to be enabled before they can be used with the PMD.
+ VFs need to be enabled before they can be used with the PMD.
Before enabling the VFs it is useful to obtain information about the
current NFP PCI device detected by the system:
-k option shows the device driver, if any, that devices are bound to.
Depending on the modules loaded at this point the new PCI devices may be
bound to nfp_netvf driver.
-
-#. **To install the uio kernel module (manually):** All major Linux
- distributions have support for this kernel module so it is straightforward
- to install it:
-
- .. code-block:: console
-
- modprobe uio
-
- The module should now be listed by the lsmod command.
-
-#. **To install the igb_uio kernel module (manually):** This module is part
- of DPDK sources and configured by default (CONFIG_RTE_EAL_IGB_UIO=y).
-
- .. code-block:: console
-
- modprobe igb_uio.ko
-
- The module should now be listed by the lsmod command.
-
- Depending on which NFP modules are loaded, it could be necessary to
- detach NFP devices from the nfp_netvf module. If this is the case the
- device needs to be unbound, for example:
-
- .. code-block:: console
-
- echo 0000:03:08.0 > /sys/bus/pci/devices/0000:03:08.0/driver/unbind
-
- lspci -d19ee: -k
-
- The output of lspci should now show that 0000:03:08.0 is not bound to
- any driver.
-
- The next step is to add the NFP PCI ID to the IGB UIO driver:
-
- .. code-block:: console
-
- echo 19ee 6003 > /sys/bus/pci/drivers/igb_uio/new_id
-
- And then to bind the device to the igb_uio driver:
-
- .. code-block:: console
-
- echo 0000:03:08.0 > /sys/bus/pci/drivers/igb_uio/bind
-
- lspci -d19ee: -k
-
- lspci should show that device bound to igb_uio driver.
-
-#. **Using scripts to install and bind modules:** DPDK provides scripts which are
- useful for installing the UIO modules and for binding the right device to those
- modules avoiding doing so manually:
-
- * **dpdk-setup.sh**
- * **dpdk-devbind.py**
-
- Configuration may be performed by running dpdk-setup.sh which invokes
- dpdk-devbind.py as needed. Executing dpdk-setup.sh will display a menu of
- configuration options.
git.droids-corp.org / dpdk.git / blobdiff