FAQ

1. Q: Is there any existing open source project with similar goals or with which this project may conflict or overlap? If yes, please identify the project and explain why we should create the ARM open source project anyway?

   A: Yes, there are some open source projects serve similar purpose, e.g., OPNFV. However, compared with the software we would like to create, OPNFV has a much larger scope for us to cover. Moreover, we would like to simply the reference solutions, focus on combining some currently being contributed networking projects, e.g., DPDK, VPP, ODP, and provide reference solutions aligned with existing marketing requirements.

   Inside the project, we will apply some optimizations applicable on Arm platform only, to achieve better performance, and those architecture specific optimizations will not be likely accepted by upstream community.

2. Q: Could you please provide the project description of functionality or purpose?

   A: The network functions this software provided serves multiple purposes of,

   1. Showcase the integration of various components and act as poof of concept to all stakeholders.

   2. Allow for performance analysis/optimization with a solution that is close to customers’ production deployment.

   3. Provide customers with a out-of-the-box reference design for rapid design modeling.

3. Q: What’s “Fixed Virtual Platforms” and what is it used for?

   A: “Fixed Virtual Platforms” are some pre-silicon simulation platforms, which could be used to develop and validate software for CPU features in early stage. Running the software on these platforms enable functional verification of software stacks for pre-silicon platforms.

4. Q: Please explain data plane and control plane, and their differences?

   A: The terms “control plane” and “data plane” are all about the separation of responsibilities within a networking system. The two most commonly referenced compositions in networking are the control plane and the data plane. The control plane is the part of a network that controls how data is forwarded, while the data plane is the actual forwarding process.

   • Control plane: refers to the all functions and processes that determine which path to use to send the packet or frame. Control plane is responsible for populating the routing table, drawing network topology, forwarding table and hence enabling the data plane functions. Control plane is the process of learning what we will do before sending the packet or frame.

   • Data plane: refers to all the functions and processes that forward packets/frames from one interface to another based on control plane logic. Routing table, forwarding table and the routing logic constitute the data plane function. Data plane packet goes through the router, and incoming and outgoing of frames are done based on control plane logic. Data plane is moving the actual packets based on what we learned from control plane.

5. Q: What’s user space Network?

   A: User space network software takes exclusive control of a network adapter, implements the whole NIC driver and develops packet processing framework completely in user space.

   There are several primary reasons to move the networking functionalities from the kernel to user space:

   • Reduce the number of context switches required to process packet data, as each syscall causes a context switch, which takes up time and resources.

   • Reduce the amount of software on the stack. Linux kernel provides abstractions, which are designed for general purpose and could be quite complicated in implementing packet processing. Customized implementation could remove unnecessary abstractions, simplify the logic, and improve performance.

   • User space drivers are easier to develop and debug than kernel drivers. Developing networking functions and getting it merge in mainline kernel would take considerable time and effort. Moreover, the function release would be bounded by Linux’s release schedule. Finally, bugs in the source code may cause the kernel to crash.

   The user space networking ecosystems has really matured since some user space networking projects are open sourced, e.g., DPDK, VPP, Snort. A whole ecosystem of technologies developed based on user space network software has emerged.

6. Q: How to install Mellanox ConnectX-5 OFED driver and update NIC firmware?

   A: To use Mellanox NIC, firstly install the OFED driver MLNX_OFED, and then update NIC Firmware.

   The key steps are:

   • Download the OFED driver

   • Install OFED driver:

   sudo mount -o ro,loop MLNX_OFED_LINUX-5.4-3.1.0.0-ubuntu20.04-aarch64.iso /mnt
   sudo /mnt/mlnxofedinstall --upstream-libs --dpdk
   

   • Install Mellanox Firmware Tools (MFT):

   wget https://www.mellanox.com/downloads/MFT/mft-4.20.0-34-arm64-deb.tgz
   tar xvf mft-4.20.0-34-arm64-deb.tgz
   cd mft-4.20.0-34-arm64-deb/
   sudo ./install.sh
   sudo mst start
   

   • Install latest firmware for the NIC:

   sudo mlxfwmanager --online -u -d <device PCIe address>
   

   • Alternatively, download a specific firmware version from Mellanox Firmware Downloads.

   To find the proper firmware to download for the NIC, first obtain its OPN and PSID via sudo mlxfwmanager -d <device PCIe address> --query. The output will look similar to:

   Querying Mellanox devices firmware ...
   
   Device #1:
   ----------
   
     Device Type:      ConnectX5
     Part Number:      MCX516A-CDA_Ax_Bx
     Description:      ConnectX-5 Ex EN network interface card; 100GbE dual-port QSFP28; PCIe4.0 x16; tall bracket; ROHS R6
     PSID:             MT_0000000013
     PCI Device Name:  0000:01:00.0
   

   The PSID is listed in the output. The OPN will resemble the part number, but may not match exactly. As an example, the OPN for the sample output is MCX516A-CDA. After downloading the desired firmware, flash that firmware to the NIC:

   sudo mlxfwmanager -d <device PCIe address> -i <path to unzipped FW download>