做嵌入式驅(qū)動(dòng)開發(fā)這些年以太網(wǎng)這個(gè)坑算是踩得最深也最有收獲的一個(gè)領(lǐng)域。從早期的百兆芯片到現(xiàn)在的千兆、2.5G從簡(jiǎn)單的RGMII到復(fù)雜的SGMII再到工業(yè)現(xiàn)場(chǎng)跟各種設(shè)備做以太網(wǎng)通訊幾乎每個(gè)項(xiàng)目都能遇到全新的問題。今天這一期我把自己在Ethernet以太網(wǎng)驅(qū)動(dòng)開發(fā)上積累的經(jīng)驗(yàn)整理出來從底層原理到實(shí)際調(diào)試從性能優(yōu)化到工業(yè)場(chǎng)景踩坑一次性說透。無論你是剛開始接觸網(wǎng)絡(luò)驅(qū)動(dòng)的新手還是已經(jīng)在MAC和PHY之間掙扎了一段時(shí)間的同行這篇內(nèi)容應(yīng)該都能提供一些參考。很多剛?cè)腴T的朋友容易把以太網(wǎng)驅(qū)動(dòng)理解為“配置寄存器、啟用DMA、收發(fā)包就完事”但實(shí)際上驅(qū)動(dòng)只是整個(gè)網(wǎng)絡(luò)路徑中的一環(huán)。你寫的是網(wǎng)卡驅(qū)動(dòng)但你的代碼要跟協(xié)議棧、PHY、甚至交換機(jī)、對(duì)端設(shè)備發(fā)生關(guān)系。所以我先說清楚以太網(wǎng)驅(qū)動(dòng)開發(fā)核心是理解數(shù)據(jù)流而不是只會(huì)翻datasheet。1. 以太網(wǎng)驅(qū)動(dòng)開發(fā)的核心思路從MAC到PHY的整體認(rèn)知1.1 網(wǎng)絡(luò)分層視角下的驅(qū)動(dòng)邊界以太網(wǎng)驅(qū)動(dòng)處于硬件和協(xié)議棧之間往上對(duì)接Linux內(nèi)核的net_device結(jié)構(gòu)體往下直接操作MAC控制器和PHY芯片。驅(qū)動(dòng)需要處理的是內(nèi)核協(xié)議棧傳來的sk_buff通過DMA發(fā)送到MAC再由PHY轉(zhuǎn)換成物理層信號(hào)反過來PHY收到的電信號(hào)經(jīng)過MAC還原成幀DMA搬到內(nèi)存再上交協(xié)議棧。我見過很多人調(diào)試網(wǎng)絡(luò)不通第一步就去看寄存器這沒錯(cuò)但容易迷失方向。更穩(wěn)妥的做法是先確認(rèn)物理層鏈路是否ok——PHY是否完成了自協(xié)商link是否established然后看MAC是否收到了幀再看DMA描述符是否有數(shù)據(jù)。這種從物理層往上層走的排查思路能讓你少走很多彎路。驅(qū)動(dòng)開發(fā)的第一個(gè)關(guān)鍵邊界是搞清楚哪些事情由硬件做哪些由驅(qū)動(dòng)做。比如CRC校驗(yàn)、幀間隙、MAC地址過濾這些絕大多數(shù)MAC硬件都做了驅(qū)動(dòng)不需要重復(fù)處理。但有些功能比如VLAN tag插入、TCP分段卸載TSO雖然硬件支持驅(qū)動(dòng)也要做很多配置和狀態(tài)維護(hù)工作。這里面的“度”沒把握好就會(huì)出現(xiàn)莫名其妙的丟包或者性能問題。第二個(gè)邊界是PHY管理。PHY芯片的寄存器空間需要通過MDIO總線訪問通常由MAC的MDIO控制器或者獨(dú)立的MDIO硬件完成。驅(qū)動(dòng)要負(fù)責(zé)PHY的復(fù)位、自協(xié)商觸發(fā)、速度/雙工模式讀取、loopback測(cè)試等。很多新人在初始化時(shí)只做一次PHY配置后續(xù)不管了結(jié)果遇到熱插拔或者對(duì)端設(shè)備切換速率鏈路就僵死。正確的做法是注冊(cè)PHY中斷或者輪詢link狀態(tài)實(shí)時(shí)響應(yīng)鏈路變化。1.2 速率與介質(zhì)1G/2.5G Ethernet 的PCS/PMA 與 SGMII 到底在說什么我們?cè)谶x型的時(shí)候經(jīng)常會(huì)看到“1G/2.5G Ethernet PCS/PMA or SGMII”這樣的描述。很多工程師一看到PCS/PMA就頭大其實(shí)它指的是PHY內(nèi)部的兩個(gè)子層。PCSPhysical Coding Sublayer負(fù)責(zé)編碼、加擾、對(duì)齊等。千兆以太網(wǎng)用的是8B/10B編碼2.5G以太網(wǎng)在SGMII接口上往往也是基于類似的編碼方式。PMAPhysical Medium Attachment負(fù)責(zé)串并轉(zhuǎn)換、時(shí)鐘恢復(fù)和信號(hào)調(diào)制。簡(jiǎn)單說PCS解決“數(shù)據(jù)怎么變成可以在線上傳輸?shù)拇a流”PMA解決“碼流怎么通過物理線纜發(fā)出去”。而SGMII是一種MAC和PHY之間的接口協(xié)議它本身是一種串行接口類似于SerDes。SGMII可以承載1Gbps或更低的速率而2.5G Ethernet的SGMII通常是2500Mbps有些芯片也支持“USXGMII”這類擴(kuò)展接口。當(dāng)你看到“1G/2.5G Ethernet PCS/PMA or SGMII”指的是PHY支持這些接口模式你需要在驅(qū)動(dòng)里通過寄存器配置選擇合適的模式。實(shí)際項(xiàng)目里我們用的主控芯片可能內(nèi)置了MAC但缺少PHY或者PHY是外掛的。MAC和PHY之間的接口常見的有RGMII千兆常用的并行接口時(shí)鐘125MHz數(shù)據(jù)雙沿采樣引腳多但布線相對(duì)簡(jiǎn)單。SGMII串行接口引腳少抗干擾強(qiáng)適合高速和板間互聯(lián)。QSGMII4個(gè)SGMII復(fù)用一對(duì)差分線主要用于交換機(jī)芯片。驅(qū)動(dòng)開發(fā)時(shí)要特別注意SGMII的自協(xié)商機(jī)制。SGMII本身也有自協(xié)商但它不是標(biāo)準(zhǔn)的802.3自協(xié)商而是MAC和PHY之間的速率協(xié)商。驅(qū)動(dòng)里需要正確配置MAC側(cè)的SGMII自適應(yīng)通常是在MAC寄存器中使能SGMII autoneg同時(shí)也要讓PHY側(cè)配合。這個(gè)配置如果不對(duì)經(jīng)常出現(xiàn)PHY link up但數(shù)據(jù)不通或者M(jìn)AC和PHY速率不一致的情況。有一種比較陰間的現(xiàn)象PHY顯示鏈接速率是1G但MAC那邊配置的是2.5G結(jié)果就是能收到一點(diǎn)數(shù)據(jù)但丟包率極高。排查這種問題需要同時(shí)讀取MAC側(cè)的狀態(tài)寄存器通常有l(wèi)ink速度指示和PHY側(cè)的速度寄存器對(duì)比兩邊是否一致。這也是我強(qiáng)調(diào)“接口配置必須兩端對(duì)齊”的原因。2. 驅(qū)動(dòng)開發(fā)中的關(guān)鍵環(huán)節(jié)接口、描述符與中斷處理2.1 從RGMII到SGMII的接口選擇與配置選擇RGMII還是SGMII很多時(shí)候不是開發(fā)人員能決定的而是硬件工程師根據(jù)板級(jí)布局和成本定的。作為驅(qū)動(dòng)開發(fā)者你需要做的是適配。RGMII的配置要點(diǎn)主要是時(shí)鐘延時(shí)。RGMII規(guī)范要求數(shù)據(jù)在時(shí)鐘的雙沿采樣但實(shí)際布線時(shí)數(shù)據(jù)信號(hào)和時(shí)鐘信號(hào)可能存在偏差。于是就有了“tx delay”和“rx delay”的概念。很多MAC和PHY都支持在內(nèi)部插入延時(shí)通過寄存器配置。例如你可以設(shè)置MAC側(cè)的TX clock delay或者讓PHY側(cè)提供RX clock delay。這個(gè)配置必須在驅(qū)動(dòng)初始化階段完成而且要跟硬件原理圖對(duì)應(yīng)。我遇到過一塊板子初始化PHY后ping不通后來發(fā)現(xiàn)是RGMII的RX延時(shí)沒有配置導(dǎo)致MAC在時(shí)鐘沿采樣數(shù)據(jù)時(shí)采到的都是毛刺。加上delay之后一切正常。所以RGMII調(diào)試時(shí)如果你不確定延時(shí)配置可以用PHY的loopback模式測(cè)試MAC側(cè)的數(shù)據(jù)通路再逐項(xiàng)排查。SGMII的配置相對(duì)簡(jiǎn)單因?yàn)樗谴胁罘志€不需要考慮并行數(shù)據(jù)的時(shí)鐘偏移。但SGMII也有自己的坑協(xié)商失敗。特別是當(dāng)對(duì)端設(shè)備是交換機(jī)或者另一個(gè)開發(fā)板時(shí)如果SGMII配置不是“自協(xié)商固定從模式”可能需要強(qiáng)制設(shè)置速度。我記得有一款PHY默認(rèn)SGMII從模式必須等到對(duì)端發(fā)送自協(xié)商配置才能建立鏈路這在有些場(chǎng)景下會(huì)導(dǎo)致長(zhǎng)時(shí)間無法link up。解決方法是把SGMII配置為master模式自己主動(dòng)發(fā)起協(xié)商。2.2 DMA描述符環(huán)設(shè)計(jì)與內(nèi)存屏障無論MAC是內(nèi)置還是外置絕大多數(shù)以太網(wǎng)控制器都使用DMA搬運(yùn)網(wǎng)絡(luò)數(shù)據(jù)避免CPU逐字節(jié)拷貝。DMA描述符環(huán)是整個(gè)驅(qū)動(dòng)的核心數(shù)據(jù)結(jié)構(gòu)它描述了一塊內(nèi)存緩沖區(qū)的位置、長(zhǎng)度、狀態(tài)等信息。驅(qū)動(dòng)需要維護(hù)發(fā)送描述符環(huán)和接收描述符環(huán)。接收描述符環(huán)的初始化尤其重要。你需要為每個(gè)描述符分配一個(gè)緩沖區(qū)sk_buff的data區(qū)并把物理地址寫入描述符。然后設(shè)置擁有權(quán)位交給硬件。硬件收到數(shù)據(jù)后會(huì)填充緩沖區(qū)并把狀態(tài)位更新為“已接收”驅(qū)動(dòng)在中斷或輪詢中掃描描述符發(fā)現(xiàn)擁有權(quán)變化就知道有數(shù)據(jù)到了。這里有幾個(gè)容易犯的錯(cuò)分配緩沖區(qū)時(shí)沒有做cache對(duì)齊。網(wǎng)絡(luò)DMA要求緩沖區(qū)物理地址對(duì)齊到cache line否則可能出現(xiàn)數(shù)據(jù)不一致。沒有處理“擁有權(quán)”標(biāo)志。有些芯片用描述符的最后一個(gè)bit來表示歸屬驅(qū)動(dòng)在回收描述符時(shí)如果寫錯(cuò)了會(huì)覆蓋硬件正在使用的描述符。環(huán)形隊(duì)列的索引管理。發(fā)送和接收的索引要明確區(qū)分“硬件當(dāng)前使用的索引”和“驅(qū)動(dòng)當(dāng)前處理的索引”兩者沒理清就會(huì)丟包或者卡死。內(nèi)存屏障也是一個(gè)關(guān)鍵點(diǎn)。CPU往描述符寫入狀態(tài)后需要確保寫入順序?qū)MA可見DMA更新狀態(tài)后CPU讀取時(shí)也需要屏障。在Linux驅(qū)動(dòng)中通常使用dma_wmb()和dma_rmb()。有朋友問過我為什么加了mb()還是有問題其實(shí)是因?yàn)閙b()是全屏障性能損耗大而且有些架構(gòu)下語義不完全匹配DMA場(chǎng)景。正確的做法是嚴(yán)格區(qū)分讀寫方向。我在調(diào)試一個(gè)eMMC和網(wǎng)絡(luò)DMA互相干擾的項(xiàng)目時(shí)發(fā)現(xiàn)描述符狀態(tài)一直讀取不到硬件更新后來檢查發(fā)現(xiàn)是描述符本身被分配到了非DMA安全區(qū)域。所以在分配描述符時(shí)一定要用dma_alloc_coherent()或者類似接口保證內(nèi)存不會(huì)被cache寫回覆蓋。2.3 中斷與輪詢的取舍以太網(wǎng)驅(qū)動(dòng)通常有兩種收包模式中斷驅(qū)動(dòng)和NAPI輪詢。中斷是及時(shí)但高吞吐時(shí)頻繁中斷會(huì)吃掉CPUNAPI是把中斷和輪詢結(jié)合起來用少量中斷配合輪詢批量收包。Linux內(nèi)核默認(rèn)使用NAPI這也是為什么netdev驅(qū)動(dòng)里都有一個(gè)poll回調(diào)。輪詢的實(shí)現(xiàn)并不復(fù)雜在中斷處理函數(shù)里關(guān)閉發(fā)送/接收中斷激活NAPI調(diào)度poll執(zhí)行。poll中循環(huán)處理發(fā)送完成和接收數(shù)據(jù)直到預(yù)算耗盡或者無包可收后重新開啟中斷。這個(gè)機(jī)制看著普通但對(duì)驅(qū)動(dòng)性能影響很大。你要合理設(shè)置weight參數(shù)比如100、200或者更大。weight越大單次poll時(shí)間越長(zhǎng)但CPU占用也高。我通常的做法是根據(jù)實(shí)際吞吐測(cè)試結(jié)果調(diào)整以CPU占用不超標(biāo)為前提盡量提高weight。還有個(gè)細(xì)節(jié)有些MAC控制器在收包時(shí)會(huì)自動(dòng)禁用接收中斷驅(qū)動(dòng)如果忘了在poll中重新開啟就會(huì)出現(xiàn)“網(wǎng)絡(luò)死”的現(xiàn)象。我在自己的驅(qū)動(dòng)里都是把“重新使能中斷”放在poll函數(shù)的最后并加一個(gè)dummy read來保證寄存器寫入順序。3. 實(shí)際調(diào)試從寄存器到數(shù)據(jù)流的排錯(cuò)實(shí)戰(zhàn)3.1 PHY 初始化與自協(xié)商狀態(tài)機(jī)PHY的初始化不是簡(jiǎn)單的reset然后配置寄存器而是要理解PHY的狀態(tài)機(jī)。PHY上電后通常處于ENERGY-DETECT狀態(tài)不斷探測(cè)介質(zhì)是否有信號(hào)。當(dāng)檢測(cè)到對(duì)端設(shè)備時(shí)進(jìn)入自協(xié)商狀態(tài)交換能力信息最終確定速率和雙工模式。驅(qū)動(dòng)里需要確保在PHY完成自協(xié)商后再去配置MAC的速率和雙工。如果MAC側(cè)先配置了錯(cuò)誤的速率即使PHY協(xié)商好了數(shù)據(jù)也發(fā)不出去。常見的做法是使用PHY驅(qū)動(dòng)的adjust_link回調(diào)在link up時(shí)讀取PHY的狀態(tài)然后更新MAC的配置。另外自協(xié)商超時(shí)問題很常見。有些PHY的寄存器配置不當(dāng)會(huì)導(dǎo)致自協(xié)商失敗或者反復(fù)重啟。調(diào)試時(shí)可以先用ethtool -s eth0 autoneg off speed 1000 duplex full強(qiáng)制固定速率確認(rèn)鏈路是否能通再排查自協(xié)商。但要注意強(qiáng)制速率時(shí)MAC側(cè)必須同步配置不能只改PHY。3.2 用Wireshark和抓包工具定位問題很多嵌入式工程師看不起抓包覺得嵌入式環(huán)境沒有條件。其實(shí)現(xiàn)在的開發(fā)板大多有兩個(gè)網(wǎng)口一個(gè)跑業(yè)務(wù)一個(gè)做管理或者用交換機(jī)鏡像端口都能方便地抓包。在驅(qū)動(dòng)調(diào)試階段我強(qiáng)烈建議盡早接上抓包工具。當(dāng)出現(xiàn)“ping不通”的情況先用Wireshark抓包看有沒有請(qǐng)求發(fā)出。如果抓不到任何幀說明數(shù)據(jù)沒有從MAC送出去問題可能在驅(qū)動(dòng)或硬件如果能抓到請(qǐng)求但收不到應(yīng)答說明請(qǐng)求到了對(duì)端對(duì)端的應(yīng)答可能沒回來或者我們的MAC沒有收到如果收到了應(yīng)答但協(xié)議棧沒反應(yīng)那可能是MAC地址、VLAN或者校驗(yàn)和的問題。我在調(diào)試一個(gè)工業(yè)網(wǎng)關(guān)時(shí)發(fā)現(xiàn)設(shè)備能被ping通但TCP連接建立失敗。抓包發(fā)現(xiàn)SYN包發(fā)出后對(duì)端回了SYN-ACK但我們的設(shè)備沒再發(fā)ACK而且不停地重傳SYN。進(jìn)一步查發(fā)現(xiàn)TCP校驗(yàn)和計(jì)算錯(cuò)誤。原因是MAC硬件開啟了TCP校驗(yàn)和卸載TX checksum offload但驅(qū)動(dòng)沒有正確設(shè)置sk_buff的ip_summed標(biāo)志導(dǎo)致硬件計(jì)算的校驗(yàn)和覆蓋了協(xié)議棧算好的值結(jié)果反而錯(cuò)了。把ip_summed設(shè)為CHECKSUM_PARTIAL之后一切正常。3.3 常見問題速查表我整理了一下這幾年遇到的最多的以太網(wǎng)驅(qū)動(dòng)問題做成表格方便大家對(duì)照排查?，F(xiàn)象可能原因排查思路link up但ping不通MAC/PHY速度不一致或RGMII延時(shí)錯(cuò)誤檢查MAC和PHY速度寄存器調(diào)整RX/TX delay測(cè)試loopback能收到包但丟包嚴(yán)重DMA描述符不足或緩沖區(qū)被覆蓋檢查描述符環(huán)大小確認(rèn)擁有權(quán)位處理正確多ring緩沖區(qū)傳輸速度只有100MPHY沒有協(xié)商上千兆或線纜/接口問題用ethtool查看自協(xié)商結(jié)果強(qiáng)制千兆測(cè)試更換線纜TCP吞吐量極低中斷頻繁或TSO/GRO未開啟開啟NAPI確認(rèn)ethtool -K支持TSO檢查中斷合并設(shè)備長(zhǎng)時(shí)間運(yùn)行后斷網(wǎng)PHY熱鏈接檢測(cè)失效或看門狗超時(shí)實(shí)現(xiàn)PHY link狀態(tài)輪詢?cè)黾渔溌坊謴?fù)流程發(fā)送方向正常接收方向不通接收DMA描述符不完整或接收中斷未使能檢查接收描述符初始化確認(rèn)中斷配置用loopback測(cè)試接收路徑無法與特定設(shè)備通訊對(duì)端設(shè)備MAC地址過濾或協(xié)議不匹配抓包確認(rèn)對(duì)端是否回包檢查MAC地址表檢查VLAN和協(xié)議字段這張表不可能是全的但覆蓋了大部分初級(jí)問題。很多時(shí)候問題不在驅(qū)動(dòng)本身而在硬件設(shè)計(jì)或者PHY配置所以在排查時(shí)要大膽假設(shè)小心驗(yàn)證。4. 工業(yè)場(chǎng)景中的以太網(wǎng)驅(qū)動(dòng)與焊機(jī)等設(shè)備通訊的經(jīng)驗(yàn)分享4.1 安川焊機(jī)以太網(wǎng)通訊的痛點(diǎn)最近一個(gè)項(xiàng)目里我需要讓嵌入式主控通過以太網(wǎng)與安川焊機(jī)通訊實(shí)現(xiàn)焊接參數(shù)下發(fā)和狀態(tài)讀取。這類工業(yè)設(shè)備使用的以太網(wǎng)協(xié)議往往不是標(biāo)準(zhǔn)TCP/IP而是基于Ethernet/IP、Profinet或特定廠商私有協(xié)議。安川焊機(jī)有些型號(hào)支持TCP/UDP但通訊報(bào)文有特定的格式要求比如首尾字節(jié)固定、CRC校驗(yàn)、數(shù)據(jù)長(zhǎng)度固定等。在這里驅(qū)動(dòng)層面其實(shí)不需要做太多特殊事情因?yàn)門CP/IP協(xié)議棧已經(jīng)替我們搞定了。真正麻煩的是應(yīng)用層的協(xié)議解析和時(shí)序控制。但從驅(qū)動(dòng)開發(fā)角度有兩個(gè)點(diǎn)需要特別留意第一工業(yè)設(shè)備的以太網(wǎng)端口通常不響應(yīng)ARP請(qǐng)求或者M(jìn)AC地址過濾嚴(yán)格。如果主控通過MAC地址白名單方式連接設(shè)備那么驅(qū)動(dòng)可能需要構(gòu)造特殊的ARP包或者干脆不用ARP直接靜態(tài)ARP表項(xiàng)。第二有些工業(yè)設(shè)備會(huì)在連接空閑時(shí)主動(dòng)斷開或者發(fā)送特定的“心跳包”。驅(qū)動(dòng)和協(xié)議棧需要配合在socket層面保持連接。否則你會(huì)發(fā)現(xiàn)過一段時(shí)間TCP連接還在但數(shù)據(jù)已經(jīng)發(fā)不過去了。另外工業(yè)現(xiàn)場(chǎng)電磁干擾嚴(yán)重網(wǎng)線很容易出現(xiàn)瞬斷。此時(shí)PHY的link狀態(tài)會(huì)反復(fù)變動(dòng)。驅(qū)動(dòng)要能快速感知link down并在link up后自動(dòng)恢復(fù)。我的做法是用內(nèi)核的PHY狀態(tài)機(jī)注冊(cè)phy_start()和phy_stop()流程配合PHY中斷每次link變化都打印日志并通知網(wǎng)絡(luò)協(xié)議棧執(zhí)行重連。4.2 協(xié)議無關(guān)的驅(qū)動(dòng)設(shè)計(jì)思路做嵌入式驅(qū)動(dòng)有時(shí)會(huì)被要求適配多種不同的設(shè)備和協(xié)議。比如同樣是焊接控制器有的用標(biāo)準(zhǔn)Modbus TCP有的用私有協(xié)議。驅(qū)動(dòng)如果做得很死每個(gè)協(xié)議都要改一遍就會(huì)很痛苦。我的建議是在驅(qū)動(dòng)層保持“協(xié)議無關(guān)”只負(fù)責(zé)把以太網(wǎng)幀正確地收發(fā)出去所有協(xié)議解析都放到上層應(yīng)用。為此驅(qū)動(dòng)需要提供干凈的接口比如注冊(cè)netdev_ops上層用socket訪問而不是在驅(qū)動(dòng)里解析業(yè)務(wù)報(bào)文。還有一點(diǎn)工業(yè)場(chǎng)景經(jīng)常用到VLAN。比如一臺(tái)設(shè)備同時(shí)連接辦公網(wǎng)和工業(yè)網(wǎng)VLAN隔離可以防止廣播風(fēng)暴。驅(qū)動(dòng)要支持VLAN offload和VLAN過濾。Linux內(nèi)核有現(xiàn)成的ndo_vlan_rx_add_vid回調(diào)驅(qū)動(dòng)只需要在寄存器中配置VLAN ID即可。我在開發(fā)支持多種工業(yè)協(xié)議的主控板時(shí)把驅(qū)動(dòng)的重點(diǎn)放在穩(wěn)定性和可配置性上。比如通過設(shè)備樹參數(shù)配置MAC地址、PHY地址、VLAN ID、速率甚至中斷觸發(fā)方式。這樣同一個(gè)驅(qū)動(dòng)二進(jìn)制就能適配不同的設(shè)備子型號(hào)節(jié)省了很多維護(hù)成本。4.3 關(guān)于Apple Mobile Device Ethernet的插曲最近熱搜里有“apple mobile device ethernet下載”這個(gè)詞一度讓我很迷惑。后來才明白這其實(shí)是指蘋果設(shè)備比如iPhone、iPad在連接電腦時(shí)通過USB拔號(hào)網(wǎng)絡(luò)或者以太網(wǎng)適配器模擬出的一個(gè)網(wǎng)絡(luò)接口。這個(gè)場(chǎng)景在物聯(lián)網(wǎng)開發(fā)里也有價(jià)值比如你想用iOS設(shè)備與嵌入式主板通訊可以通過雷電轉(zhuǎn)以太網(wǎng)適配器或者通過USB共享網(wǎng)絡(luò)。從驅(qū)動(dòng)開發(fā)的視角當(dāng)你把蘋果設(shè)備插入電腦系統(tǒng)會(huì)識(shí)別出一個(gè)“Apple Mobile Device Ethernet”設(shè)備這個(gè)設(shè)備本質(zhì)上是一個(gè)USB網(wǎng)卡。它的驅(qū)動(dòng)是蘋果官方提供的在macOS和Windows上都有。對(duì)嵌入式開發(fā)者來說相關(guān)經(jīng)驗(yàn)就是你的嵌入式設(shè)備如果支持USB gadget的RNDIS或者ECM協(xié)議也可以被電腦識(shí)別為一個(gè)虛擬網(wǎng)卡從而進(jìn)行網(wǎng)絡(luò)調(diào)試。但要注意蘋果設(shè)備的以太網(wǎng)接口默認(rèn)可能只支持特定速率和協(xié)議。所以如果你用自研的設(shè)備去跟蘋果設(shè)備通訊最好先確認(rèn)雙方的USB以太網(wǎng)類兼容性特別是驅(qū)動(dòng)中的描述符配置。這里就不展開細(xì)說了但至少說明以太網(wǎng)驅(qū)動(dòng)并不局限于物理網(wǎng)口還包含USB虛擬網(wǎng)卡等形態(tài)。5. 驅(qū)動(dòng)性能優(yōu)化與穩(wěn)定性保障5.1 吞吐量?jī)?yōu)化零拷貝與多隊(duì)列當(dāng)你的驅(qū)動(dòng)能正常收發(fā)數(shù)據(jù)之后性能和穩(wěn)定性就是下一步目標(biāo)。在嵌入式平臺(tái)上吞吐量的瓶頸往往不是網(wǎng)絡(luò)帶寬而是內(nèi)存拷貝和中斷開銷。零拷貝是一個(gè)繞不開的話題。Linux協(xié)議棧的sk_buff本身支持headroom和frag機(jī)制驅(qū)動(dòng)在接收數(shù)據(jù)時(shí)最好讓DMA直接填充到sk_buff的數(shù)據(jù)區(qū)避免額外拷貝一次。發(fā)送方向則可以利用sendpage或者M(jìn)SG_ZEROCOPY讓協(xié)議棧的數(shù)據(jù)直接進(jìn)入DMA描述符。多隊(duì)列RSS/Flow PIR在高吞吐場(chǎng)景下很重要。如果MAC支持多隊(duì)列你可以把不同數(shù)據(jù)流的包分配到不同的DMA通道和CPU核心極大提升并發(fā)處理能力。但嵌入式CPU核心數(shù)不多多隊(duì)列也可能帶來更多中斷需要根據(jù)實(shí)際情況權(quán)衡。我在一個(gè)四核ARM平臺(tái)上把單個(gè)隊(duì)列改成雙隊(duì)列并綁定兩個(gè)中斷到不同的CPU核心吞吐量提升了約30%。代價(jià)是CPU占用率從60%升到了70%但整體吞吐從900Mbps提升到了1.2Gbps基于2.5G網(wǎng)口。所以多隊(duì)列不是萬能的但值得嘗試。5.2 電源管理與鏈路檢測(cè)嵌入式設(shè)備對(duì)功耗敏感網(wǎng)絡(luò)驅(qū)動(dòng)的電源管理往往容易被忽略。MAC和PHY通常都有低功耗模式但在進(jìn)入低功耗前要確保沒有未完成的DMA傳輸。否則數(shù)據(jù)寫到一半設(shè)備睡眠醒來后描述符狀態(tài)不一致就會(huì)導(dǎo)致驅(qū)動(dòng)卡死。鏈路檢測(cè)要盡量不依賴定時(shí)器最好用PHY中斷。有些PHY支持活動(dòng)中斷和link狀態(tài)變化中斷驅(qū)動(dòng)在link_change回調(diào)中執(zhí)行相應(yīng)操作。如果PHY不支持中斷就只能周期性地讀寄存器但輪詢間隔不能太短建議2秒左右。太短會(huì)增加功耗太長(zhǎng)則反應(yīng)遲鈍。我遇到過一個(gè)項(xiàng)目設(shè)備為了省電在空閑時(shí)關(guān)閉PHY但喚醒時(shí)總是出現(xiàn)第一次ping不通。后來發(fā)現(xiàn)喚醒后PHY的自協(xié)商需要幾秒而網(wǎng)絡(luò)協(xié)議棧已經(jīng)在喚醒后立刻發(fā)起了ARP請(qǐng)求。解決方法是在驅(qū)動(dòng)喚醒流程中等待PHY完成自協(xié)商后再上報(bào)__LINK_STATE_START或者通過netif_carrier_on()延遲上報(bào)link。5.3 長(zhǎng)期穩(wěn)定運(yùn)行的注意事項(xiàng)嵌入式設(shè)備往往要求7x24小時(shí)運(yùn)行驅(qū)動(dòng)在這種環(huán)境下最容易出現(xiàn)的問題是內(nèi)存泄漏和描述符耗盡。內(nèi)存泄漏可能來自每個(gè)收包分發(fā)的緩沖區(qū)沒有正確釋放。我在檢查一個(gè)老代碼時(shí)發(fā)現(xiàn)接收路徑中每次丟包都直接調(diào)用dev_kfree_skb_any()但有些分支沒有釋放導(dǎo)致內(nèi)存緩慢增長(zhǎng)。這類問題很難查需要借助kmemleak工具或者定期查看/proc/net/skbuff這樣的信息。描述符耗盡也常見。比如發(fā)送路徑中如果上層快速發(fā)送大量小包而驅(qū)動(dòng)沒有及時(shí)回收發(fā)送完成描述符環(huán)形隊(duì)列會(huì)滿導(dǎo)致NETDEV_TX_BUSY。解決方法是在發(fā)送的時(shí)候檢查描述符是否夠用不夠用就停止發(fā)送隊(duì)列等完成中斷后重啟隊(duì)列。這個(gè)邏輯我每次都會(huì)認(rèn)真檢查因?yàn)橐粋€(gè)簡(jiǎn)單的錯(cuò)誤就會(huì)造成死鎖。另外建議給驅(qū)動(dòng)添加debugfs接口可以手動(dòng)查看描述符環(huán)狀態(tài)、PHY寄存器、中斷統(tǒng)計(jì)。我在正式項(xiàng)目中一定會(huì)在debugfs里面放一個(gè)“手動(dòng)觸發(fā)link down再恢復(fù)”的測(cè)試入口方便生產(chǎn)測(cè)試和現(xiàn)場(chǎng)排查。這不難但對(duì)故障定位非常有幫助。結(jié)語最后分享一個(gè)我自己的習(xí)慣。每次寫以太網(wǎng)驅(qū)動(dòng)我都會(huì)先把PHY的寄存器表打印出來保存一份完整的狀態(tài)基線。一旦后續(xù)出現(xiàn)通訊問題我可以快速對(duì)比寄存器值判斷是PHY配置變了還是硬件鏈路有問題。這個(gè)方法幫我解決了不少“莫名其妙”的網(wǎng)絡(luò)故障。如果你也是做嵌入式驅(qū)動(dòng)開發(fā)的不妨試試。另外記得在驅(qū)動(dòng)代碼里加足夠多的日志別嫌麻煩關(guān)鍵時(shí)刻就是這些日志救了你。