查詢系統版本和架構
下載對應系統版本架構的網卡驅動
上傳網卡驅動安裝文件到服務器
檢查系統是否識別到網卡設備
掛載或者解壓驅動包，安裝網卡驅動
配置網卡靜態ip地址
使用驅動自帶性能測試工具測試網卡性能
1. 查詢系統版本和架構
本文以CentOS 8.2 為例，演示安裝 NVIDIA/Mellanox 網卡驅動過程。
查詢系統信息：
[root@vincent-pc2 ~]# cat /etc/centos-releaseCentOS Linux release 8.2.2004 (Core)
查詢架構：
[root@vincent-pc2 ~]# uname -mx86_64
2. 下載對應系統版本架構的網卡驅動
到官方驅動下載頁面，選擇對應系統版本架構，下載驅動安裝包，根據上一步驟查詢到的信息，我們選擇RHEL/CentOS 8.2 x86_64
對于Version 版本，想要體驗最新版本，就選擇第一個，對穩定性和可靠性有要求的，建議選擇 LTS 版本。
驅動包文件提供了3種類型的下載，通常選擇ISO或者tgz，不建議使用源碼包。
3. 上傳驅動安裝包文件到服務器
3.1 從Windows系統上傳驅動包到服務器
如果你使用Windows 系統，瀏覽器默認下載驅動包到系統“下載”目錄，推薦使用Windows的scp命令直接上傳文件到服務器。
使用快捷鍵 Windows + R ，輸入 powershell，打開powershell 終端。
打開powershell終端后，默認在用戶目錄，切換到“下載”目錄，上傳驅動包文件到服務器.
4. 檢查網卡設備
在正式安裝驅動之前，建議先檢查服務器是否硬件已經識別到網卡設備
[root@vincent-pc2 ~]# lspci |grep Mellanox
01:00.0 Infiniband controller: Mellanox Technologies MT27800 Family [ConnectX-6]
[root@vincent-pc2 ~]#
有類似以上 輸出代表主機已識別到一張 Mellanox [ConnectX-6] 網卡
5. 安裝驅動
如果下載的驅動包文件格式 為ISO，那么掛載，如果是tgz包就直接解壓，進入解壓后的目錄開始安裝。
ISO 方式：
[root@vincent-pc2 ~]# mount MLNX_OFED_LINUX-23.07-0.5.0.0-rhel8.2-x86_64.iso /mntmount: /mnt: WARNING: device write-protected, mounted read-only.[root@vincent-pc2 ~]# cd /mnt[root@vincent-pc2 mnt]# ./mlnxofedinstall --all --force
如果遇到提示缺少依賴包，請按照提示安裝對應的依賴包，比如下面的包，安裝依賴結束后，重新執行安裝驅動腳本：
yum install gcc-gfortran tcl tcsh kernel-modules-extra python36 tk
如果遇到類似提示，說明系統內核已更新，驅動需要重新支持新內核
[root@vincent-pc2 mnt]# ./mlnxofedinstall --all --forceLogs dir: /tmp/MLNX_OFED_LINUX.6221.logsGeneral log file: /tmp/MLNX_OFED_LINUX.6221.logs/general.logVerifying KMP rpms compatibility with target kernel...The kernel KMP rpms coming with MLNX_OFED_LINUX are not compatible with kernel: 4.18.0-348.7.1.el8_5.x86_64
使用內核支持參數重新安裝驅動：
[root@vincent-pc2 mnt]# ./mlnxofedinstall --add-kernel-support
如果提示缺少相關依賴包，按照提示安裝相應的包
yum install gdb-headless rpm-build libtool autoconf kernel-devel-4.18.0-348.7.1.el8_5.x86_64 kernel-rpm-macros python36-devel automake patch
還要安裝一個rmpbuild 工具包：
yum install createrepo elfutils-libelf-devel
運行 內核支持參數，安裝腳本將會重新生成對應系統內核的安裝包文件，編譯文件，然后安裝驅動，需要較長的時間，請耐心等待，大概半小時。
驅動安裝過程大概持續10分鐘左右，請耐心等待。
安裝完成后，提示重啟驅動：
[root@vincent-pc2 mnt]# /etc/init.d/openibd restart
Unloading HCA driver: [ OK ]
Loading HCA driver and Access Layer: [ OK ]
[root@vincent-pc2 mnt]#
查看驅動版本：
[root@vincent-pc2 ~]# ofed_info -sMLNX_OFED_LINUX-23.07-0.5.0.0:
6. 配置網卡靜態ip地址
[root@vincent-pc2 mnt]# ibdev2netdevmlx5_0 port 1==> ib0 (Down)[root@vincent-pc2 mnt]# cd /etc/sysconfig/network-scripts/[root@vincent-pc2 network-scripts]# vi ifcfg-ib0TYPE=InfiniBandBOOTPROTO=noneNAME=ib0DEVICE=ib0ONBOOT=yesIPADDR=10.10.10.242NETMASK=255.255.255.0[root@vincent-pc2 ~]# ibdev2netdevmlx5_0 port 1==> ib0 (Up)
7. 使用驅動自帶性能測試工具測試網卡性能
通常使用到的測試命令：
帶寬測試：
ib_write_bw
ib_send_bw
ib_read_bw
延時測試：
ib_write_lat
ib_send_lat
ib_read_lat
注意：測試前需要關閉防火墻，或者放行測試工具的默認端口號 18515
使用方法，至少使用2臺服務器，一臺開啟服務端，另外一臺開啟客戶端去訪問服務端。
服務端
在pc1開啟服務端：假設服務端ib網卡IP地址為 10.10.10.241/24
[root@vincent-pc1 ~]# ib_write_bw --report_gbits -d mlx5_0
客戶端
在pc2開啟客戶端去訪問服務端：
[root@vincent-pc2 ~]# ib_write_bw --report_gbits -d mlx5_0 -D 30 10.10.10.241
說明:
--report_gbits # 以Gb/s 為單位顯示測試結果
-D 30 # 測試時長 30 秒
以下是一個 ib_write_bw 測試截圖
8. 常見問題和診斷：
8.1 IB交換機端口狀態LED燈處于橙色狀態，或者網卡處于初始化狀態 State：Initializing
root@ubuntu02:~# ibstatCA 'mlx5_0' CA type: MT4123 Number of ports: 1 Firmware version: 20.37.1014 Hardware version: 0 Node GUID: 0xb88303ffff9ec6dc System image GUID: 0xb88303ffff9ec6dc Port 1: State: Initializing Physical state: LinkUp Rate: 100 Base lid: 65535 LMC: 0 SM lid: 0 Capability mask: 0xa651e84a Port GUID: 0xb88303ffff9ec6dc Link layer: InfiniBand
網卡處于初始化，說明IB子網中，子網管理器（SM）沒有開啟，開啟SM常見的2種方式：在交換機或者服務器(選擇其一即可)
在帶管理的IB交換機（SB7800，QM8700，QM9700）開啟SM：
ibswitch [standalone: master] > enableibswitch [standalone: master] # configure terminalibswitch [standalone: master] (config) # ib smnode ibswitch enableibswitch [standalone: master] (config) # show ib smenableibswitch [standalone: master] (config) # write memory
在服務器開啟子網管理器，建議在2臺服務器開啟SM：
root@ubuntu02:~# /etc/init.d/opensmd startStarting opensmd (via systemctl): opensmd.service.
root@ubuntu02:~# ibstatCA 'mlx5_0' CA type: MT4123 Number of ports: 1 Firmware version: 20.37.1014 Hardware version: 0 Node GUID: 0xb88303ffff9ec6dc System image GUID: 0xb88303ffff9ec6dc Port 1: State: Active Physical state: LinkUp Rate: 200 Base lid: 1 LMC: 0 SM lid: 1 Capability mask: 0xa651e84a Port GUID: 0xb88303ffff9ec6dc Link layer: InfiniBand
憑借卓越的內存效率、速度與安全性等特點，近幾年 Rust 可謂深受大廠青睞：
2019 年，AWS 表示開始在其基礎架構中越來越多地使用 Rust 后，決定贊助 Rust，即 Rust 團隊可以優惠租用 AWS 基礎設施以進行語言開發。
2021 年 2 月 9 日，Rust 基金會成立，Mozilla、亞馬遜、華為、谷歌和微軟作為創始白金成員，承諾在兩年時間里每年投入不少于 100 萬美元的預算，以用于 Rust 項目的開發、維護和推廣。
2022 年，Meta 宣布將 Rust 語言納入其服務器端編程語言。
2022 年 12 月，Linux 內核 6.1 發布，包含了初始 Rust 支持。
今年年初，谷歌宣布支持使用 Rust 開發 Chromium。
……
在這眾多大廠之中，微軟對于 Rust 的重視與支持力度也一直未減。繼 5 月效仿 Linux 用 Rust 重寫部分 Windows 內核后，近來微軟在擁抱 Rust 上又進了一步：微軟在 GitHub 中發布了一系列開發工具包，讓開發者可以使用 Rust 語言來編寫 Windows 驅動程序。
對此，不少開發者在感慨：沒想到啊，Windows 在擁抱 Rust 方面居然走在了 Linux 前面！
在擁抱 Rust 的路上，微軟曾遭到反對
事實上，早在 2019 年 2 月，微軟工程師 Matt Miller 在以色列舉行的安全會議 BlueHat 上曾透露：從 2006 年到 2018 年，微軟旗下產品過去 12 年修復的所有漏洞中，有七成涉及的都是內存安全問題。
內存安全問題占比高的原因，主要是因為 Windows 大多是以 C 和 C++ 編寫的——著名的“內存不安全”語言。內存管理代碼只要有一個漏洞，就會導致大量的內存安全錯誤，從而可能引發遠程代碼執行或權限提升漏洞等攻擊。
對于這些潛在風險，同年 7 月微軟研究院發布了一份聲明，希望“在漏洞發生之前消除一整類漏洞”，并表示“滿足這些要求的最有前途的新系統編程語言之一，就是最初由 Mozilla 發明的 Rust”。從這份聲明可以看出，至少自 2019 年開始，微軟已打算在擁抱 Rust 上積極布局。
到了去年 9 月，微軟 Azure 首席技術官 Mark Russinovich 在 X（前推特）上發文，正式呼吁業界淘汰 C / C++，應改用更加安全的 Rust 語言：
說到語言，現在是時候停止用 C/C++ 啟動任何新項目了，在需要使用非 GC 語言的情況下使用 Rust。為了安全性和可靠性，業界應該宣布這些語言已被淘汰。
可不同于 Mark Russinovich 對 Rust 的支持和青睞，當時他的這則帖子下多是反對和質疑的聲音：“這完全是一個與顯示脫節、不切實際的想法。”
“這聽起來像是在指責語言本身而不是程序員。C++ 是門好語言，只是許多使用它的人基本上不懂編程，而換一種語言并不能解決這個問題。”
“Rust 是一種不錯的語言，但它甚至還未達到 1.0 版本，我認為我們不應該為了尚未經過實戰檢驗的語言而放棄久經考驗的語言。”
盡管不被看好，但微軟轉向 Rust 的決心依舊堅定。今年 5 月 Mark Russinovich 宣布微軟已用 Rust 重寫部分 Windows 內核：“如果你在 Windows 11 Insider ring 上，那么將首次感受到 Rust 在 Windows 內核中帶來的魔力。”
當時，或許是網友對微軟擁抱 Rust 的決定已逐漸接受，也或許是微軟解釋過并非是用 Rust 替換內核中 C/C++ 的整個“40 年工作”，而是將其中一些內部的 C++ 數據類型替換成 Rust，因此在這則帖子下大多是正面留言。
從 2019 年放出風聲，到已用 Rust 重寫部分 Windows 11 內核代碼，如今微軟擁抱 Rust 的程度仍在繼續加深：在 Github 上發布工具包，讓開發者能用 Rust 編寫 Windows 驅動程序——這無疑是為操作系統實現內存安全編程的關鍵一步。
仍處于早期開發階段，不建議“用于商業用途”
從 Mark Russinovich 在 X 上分享的 Github 鏈接來看，這個由微軟 Surface 團隊開發的新項目名為 windows-drivers-rs，是一個由多個 Rust 組件（Crates）組成的項目，可幫助開發人員用 Rust 開發 Windows 驅動程序。
該項目同時支持 WDM（Windows Driver Model）和 WDF（Windows Driver Foundation）兩種不同的驅動程序開發模型：WDM 驅動程序級別較低，與操作系統緊密相連，而 WDF 驅動程序則通過框架庫與系統交互。
據介紹，windows-drivers-rs 具體包含以下板塊：
wdk-build：一個用于配置 Cargo 構建腳本的庫，可用于綁定生成和 WDK（Windows Developer Kit）的下游鏈接。
wdk-sys：將 FFI 直接綁定到 WDK 中提供的 API。
wdk：與 WDK 中的 API 安全綁定。
wdk-panic：使用 WDK 構建的程序的默認 panic 處理程序實現。
wdk-alloc：為使用 WDK 編譯的二進制文件提供分配支持。
wdk-macros：宏集合，有助于更輕松地與 wdk-sys 的直接綁定進行交互。
如需查看 windows-drivers-rs 用于創建驅動程序的示例，開發者可前往：https://github.com/microsoft/Windows-rust-driver-samples。
值得注意的是，微軟補充：雖然該項目的計劃靈活運用不同的 WDK 版本和不同的 WDF 版本，但目前“僅針對 NI eWDK、KMDF 1.33、UMDF 2.33 和 WDM 驅動程序進行了測試”，對于“較舊的 DDK 可能會缺少鏈接器選項”。
此外，微軟還表示 windows-drivers-rs 目前仍處于早期開發階段，因此“不建議用于商業用途”，但鼓勵社區和開發者對其進行試驗、建議和反饋，并將利用 GitHub 論壇作為與社區互動的主要形式。
開發者提問：Rust 如何處理異常？
就目前而言，已有少數開發者提出了當前這個旨在助力開發者用 Rust 開發 Windows 驅動程序的新工具平臺存在的一些問題，其中一個引起討論的問題就是 Rust 如何處理異常。
一位開發者指出：“對于 Windows 內核（以及整個操作系統）來說，結構化異常處理是 Windows 開發不可或缺的一部分，也是讓 Rust 成為 Windows 內核開發現實的真正障礙。”
但與其他編程語言不同，在 Rust 語言中沒有異常這一說，它通常用 Result 類型來處理可恢復的錯誤，而在遇到不可恢復的錯誤時，Rust 會提供一個特殊的宏 panic!。當執行這個宏時，程序會打印一段錯誤提示信息，展開（unwind）并清理當前的棧（Stack），然后退出程序的執行。
正如另一位開發者所說，“Windows 內核中的 Panic 往往是最后的手段，只應保留給內核已損壞且無法恢復的情況”，因此不少人認為 Rust 調用 Panic 的方式“在內核代碼中是不可取的，這可能會導致系統崩潰”。
那么，你對于 Rust 進一步入駐 Windows 的趨勢又有何看法呢？
參考鏈接：
https://github.com/microsoft/windows-drivers-rs
https://devclass.com/2023/09/25/microsoft-posts-early-stages-code-for-developing-windows-drivers-in-rust/
歡迎參與 CSDN 重磅發起的《2023 AI 開發者生態調查問卷》，分享您真實的 AI 使用體驗，更有精美好禮等你拿！