網路流處理器 (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 指的是上面的第二列。