网络流处理器 (NFP) 内核驱动程序

版权:

© 2019, Netronome Systems, Inc.

版权:

© 2022, Corigine, Inc.

目录

概述

此驱动程序支持 Netronome 和 Corigine 的网络流处理器设备系列,包括 NFP3800、NFP4000、NFP5000 和 NFP6000 型号,这些型号也包含在这些公司的 Agilio SmartNIC 系列中。该驱动程序支持这些设备的 SR-IOV 物理和虚拟功能。

获取固件

NFP3800、NFP4000 和 NFP6000 设备需要特定的应用程序固件才能运行。应用程序固件可以位于主机文件系统上或设备闪存中(如果管理固件支持)。

主机文件系统上的固件文件包含卡类型 (AMDA-* 字符串)、媒体配置等。它们应放置在 /lib/firmware/netronome 目录中,以便从主机文件系统加载固件。

用于基本 NIC 操作的固件可在上游 linux-firmware.git 存储库中找到。

更全面的固件列表可以从 Corigine 支持站点下载。

NVRAM 中的固件

最近版本的管理固件支持在主机驱动程序被探测时从闪存加载应用程序固件。固件加载策略配置可用于适当地配置此功能。

Devlink 或 ethtool 可用于通过向相应命令提供相应的 nic_AMDA*.nffw 文件来更新设备闪存上的应用程序固件。用户需要注意将正确的固件映像写入闪存,以用于卡和媒体配置。

闪存中的可用存储空间取决于正在使用的卡。

处理多个项目

NFP 硬件是完全可编程的,因此可能存在针对不同应用程序的不同固件映像。

当使用来自主机的应用程序固件时,我们建议将实际固件文件放置在 /lib/firmware/netronome 中以应用程序命名的子目录中,并链接所需的文件,例如:

$ tree /lib/firmware/netronome/
/lib/firmware/netronome/
├── bpf
│   ├── nic_AMDA0081-0001_1x40.nffw
│   └── nic_AMDA0081-0001_4x10.nffw
├── flower
│   ├── nic_AMDA0081-0001_1x40.nffw
│   └── nic_AMDA0081-0001_4x10.nffw
├── nic
│   ├── nic_AMDA0081-0001_1x40.nffw
│   └── nic_AMDA0081-0001_4x10.nffw
├── nic_AMDA0081-0001_1x40.nffw -> bpf/nic_AMDA0081-0001_1x40.nffw
└── nic_AMDA0081-0001_4x10.nffw -> bpf/nic_AMDA0081-0001_4x10.nffw

3 directories, 8 files

在那些使用旧的 mkinitrd 命令而不是 dracut 的发行版上(例如 Ubuntu),您可能需要使用硬链接而不是符号链接。

更改固件文件后,您可能需要重新生成 initramfs 映像。Initramfs 包含您的系统可能需要引导的驱动程序和固件文件。请参阅您的发行版的文档以了解如何更新 initramfs。Stale initramfs 的一个很好的迹象是系统在启动时加载错误的驱动程序或固件,但是当稍后手动重新加载驱动程序时,一切正常。

为每个设备选择固件

最常见的是,系统上的所有卡都使用相同类型的固件。如果要为特定卡加载特定的固件映像,可以使用 PCI 总线地址或序列号。当驱动程序识别到 NFP 设备时,它将打印它正在查找的文件。

nfp: Looking for firmware file in order of priority:
nfp:  netronome/serial-00-12-34-aa-bb-cc-10-ff.nffw: not found
nfp:  netronome/pci-0000:02:00.0.nffw: not found
nfp:  netronome/nic_AMDA0081-0001_1x40.nffw: found, loading...

在这种情况下,如果文件(或链接)名为 *serial-00-12-34-aa-bb-5d-10-ff.nffw* 或 *pci-0000:02:00.0.nffw* 存在于 /lib/firmware/netronome 中,则此固件文件将优先于 nic_AMDA* 文件。

请注意,serial-*pci-* 文件**不会**自动包含在 initramfs 中,您将必须参考相应工具的文档以了解如何包含它们。

运行固件版本

可以使用 ethtool 命令显示特定 <netdev> 接口(例如 enp4s0)或接口端口 <netdev port>(例如 enp4s0np0)的已加载固件版本。

$ ethtool -i <netdev>

固件加载策略

固件加载策略由三个 HWinfo 参数控制,这些参数作为键值对存储在设备闪存中

app_fw_from_flash

定义哪个固件应该优先,'Disk' (0)、'Flash' (1) 或 'Preferred' (2) 固件。当选择 'Preferred' 时,管理固件通过比较闪存固件和主机提供的固件的版本来决定将加载哪个固件。可以使用 'fw_load_policy' devlink 参数配置此变量。

abi_drv_reset

定义当驱动程序被探测时是否应重置固件,如果驱动程序在磁盘上找到固件则为 ‘Disk’ (0),'Always' (1) 重置或 'Never' (2) 重置。请注意,如果驱动程序被探测时加载了固件,则在驱动程序卸载时始终会重置设备。可以使用 'reset_dev_on_drv_probe' devlink 参数配置此变量。

abi_drv_load_ifc

定义允许在设备上加载 FW 的 PF 设备列表。此变量当前不可由用户配置。

配置设备

本节介绍如何使用运行基本 NIC 固件的 Agilio SmartNIC。

配置接口最大传输单元 (MTU)

可以使用 iproute2、ip link 或 ifconfig 工具临时设置接口的 MTU。请注意,此更改不会持久保留。建议通过 Network Manager 或其他合适的操作系统配置工具进行设置,因为可以使用 Network Manager 对 MTU 进行更改以使其持久保留。

将接口 MTU 设置为 9000 字节

$ ip link set dev <netdev port> mtu 9000

用户或编排层有责任在处理巨型帧或利用隧道时设置适当的 MTU 值。例如,如果从 VM 发送的数据包将在卡上进行封装并从物理端口发送出去,则应将 VF 的 MTU 设置为低于物理端口的 MTU,以考虑额外标头添加的字节。如果设置预计会在 SmartNIC 和内核之间看到回退流量,则用户还应确保正确设置 PF MTU,以避免此路径上出现意外丢弃。

配置前向纠错 (FEC) 模式

Agilio SmartNIC 支持 FEC 模式配置,例如自动、Firecode Base-R、ReedSolomon 和关闭模式。可以使用 ethtool 独立设置每个物理端口的 FEC 模式。可以使用以下命令查看接口支持的 FEC 模式

$ ethtool <netdev>

可以使用以下命令查看当前配置的 FEC 模式

$ ethtool --show-fec <netdev>

要强制特定端口的 FEC 模式,必须禁用自动协商(请参阅自动协商部分)。以下是将 FEC 模式设置为 Reed-Solomon 的示例

$ ethtool --set-fec <netdev> encoding rs

自动协商

要更改自动协商设置,必须先关闭链路。链路关闭后,可以使用以下命令启用或禁用自动协商

ethtool -s <netdev> autoneg <on|off>

统计信息

以下设备统计信息可通过 ethtool -S 接口获得

NFP 设备统计信息

名称

ID

含义

dev_rx_discards

1

数据包可能由于以下原因之一在 RX 路径上被丢弃

  • NIC 不处于混杂模式,并且目标 MAC 地址与接口的 MAC 地址不匹配。

  • 接收到的数据包大于主机上的最大缓冲区大小。即,它超过了第 3 层 MRU。

  • 主机上没有可用于该数据包的空闲列表描述符。NIC 很可能无法及时缓存一个。

  • BPF 程序丢弃了该数据包。

  • 执行了数据路径丢弃操作。

  • MAC 由于 NIC 上缺少入口缓冲区空间而丢弃了该数据包。

dev_rx_errors

2

由于以下原因,数据包可能会被计数(和丢弃)为 RX 错误

  • VEB 查找存在问题(仅当使用 SR-IOV 时)。

  • 导致以太网错误的物理层问题,例如 FCS 或对齐错误。通常原因是电缆或 SFP 模块故障。

dev_rx_bytes

3

接收的总字节数。

dev_rx_uc_bytes

4

接收的单播字节数。

dev_rx_mc_bytes

5

接收的多播字节数。

dev_rx_bc_bytes

6

接收的广播字节数。

dev_rx_pkts

7

接收的总数据包数。

dev_rx_mc_pkts

8

接收的多播数据包数。

dev_rx_bc_pkts

9

接收的广播数据包数。

dev_tx_discards

10

如果 MAC 被流控并且网卡 TX 队列空间不足,则数据包可能在 TX 方向上被丢弃。

dev_tx_errors

11

由于以下原因之一,数据包可能被计数为 TX 错误(并被丢弃):

  • 该数据包是 LSO 片段,但无法确定第 3 层或第 4 层偏移量。因此,LSO 无法继续。

  • 通过 PCIe 接收到无效的数据包描述符。

  • 数据包第 3 层长度超过设备 MTU。

  • MAC/物理层出现错误。通常是由于电缆或 SFP 模块故障。

  • 无法分配 CTM 缓冲区。

  • 数据包偏移量不正确,网卡无法修复。

dev_tx_bytes

12

发送的总字节数。

dev_tx_uc_bytes

13

发送的单播字节数。

dev_tx_mc_bytes

14

发送的多播字节数。

dev_tx_bc_bytes

15

发送的广播字节数。

dev_tx_pkts

16

发送的总数据包数。

dev_tx_mc_pkts

17

发送的多播数据包数。

dev_tx_bc_pkts

18

发送的广播数据包数。

请注意,驱动程序未知的统计信息将显示为 dev_unknown_stat$ID,其中 $ID 指的是上面的第二列。