网络流处理器 (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` 目录中,以便从主机文件系统加载固件。

基本网卡操作所需的固件可在上游 `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。判断 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...

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

请注意,`serial-*` 和 `pci-*` 文件不会自动包含在 initramfs 中,您需要查阅相关工具的文档以了解如何包含它们。

运行中的固件版本

特定 `` 接口(例如 enp4s0)或接口端口 ``(例如 enp4s0np0)的已加载固件版本可以通过 ethtool 命令显示:

$ ethtool -i <netdev>

固件加载策略

固件加载策略通过存储在设备闪存中作为键值对的三个 HWinfo 参数控制:

app_fw_from_flash

定义哪种固件应优先,是“磁盘”(0)、“闪存”(1)还是“首选”(2)固件。当选择“首选”时,管理固件通过比较闪存固件和主机提供的固件版本来决定加载哪种固件。此变量可通过“fw_load_policy”devlink 参数进行配置。

abi_drv_reset

定义驱动程序在探测时是否应重置固件:如果磁盘上找到固件则“磁盘”(0)重置,或者“总是”(1)重置,或者“从不”(2)重置。请注意,如果驱动程序在探测时加载了固件,则在驱动程序卸载时设备总是会被重置。此变量可通过“reset_dev_on_drv_probe”devlink 参数进行配置。

abi_drv_load_ifc

定义允许在设备上加载固件的 PF 设备列表。此变量目前不支持用户配置。

配置设备

本节解释了如何使用运行基本网卡固件的 Agilio SmartNIC。

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

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

将接口 MTU 设置为 9000 字节

$ ip link set dev <netdev port> mtu 9000

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

配置前向纠错 (FEC) 模式

Agilio SmartNIC 支持 FEC 模式配置,例如自动、Firecode Base-R、ReedSolomon 和关闭模式。每个物理端口的 FEC 模式可以使用 ethtool 独立设置。接口支持的 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 路径上可能因以下原因之一而被丢弃:

  • 网卡不在混杂模式下,并且目的 MAC 地址与接口的 MAC 地址不匹配。

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

  • 主机上没有可用于该数据包的空闲列表描述符。很可能是网卡未能及时缓存。

  • BPF 程序丢弃了数据包。

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

  • 由于网卡上入口缓冲区空间不足,MAC 丢弃了数据包。

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 指的是上面的第二列。