繼上次使用大量封包測試效能因為設備問題受阻後,這次想要研究該paper另一種測試方式:測試latency。較為理想的狀態為使用timestamp,這個之前有做過類似的,但測試結果較為受限。
詳見 https://hackmd.io/@nemoz/HJ4J3RNG5 。
由於是在Sender端傳出時就打上timestamp,所以會吃到Sender端network stack、連線的狀況及品質等,因此想在"Reciever NIC接收到封包後"第一時間打上timestamp,也就是將latency指代的data path從
轉變為
因此第一時間就想到正仁學長在課堂時分享的bcc專案:BPF Compiler Collection,對照上面的圖找到了可以監聽封包的最底層的工具:tcpdump,此工具可以讀取driver送上kernel的封包資訊及timestamp。
但結果是若開啟了XDP類型的firewall,tcpdump就收不到封包了,原因為下圖:
tcpdump是運用libpcap,將function hook在nwetwork stack的中段,因此是比XDP程式還要更上層的,必須要能夠在XDP進行過濾前先行打上timestamp。
為了要比XDP早取得封包的資料並標上timestamp,必須也使用XDP來標記timestamp。
https://github.com/xdp-project/xdp-tools
此專案之前正仁學長也有用過,他分為兩個主要我們會用到的部分:
我們先透過
將xdpfilter程式load進driver,並標明透過ipv4來過濾封包。
再透過
告訴xdpfilter我們所要濾掉來自192.168.69.9的所有封包。
接著我們開啟xdpdump程式。
透過–rx-capture來嗅出即將"進入"xdpfilter的封包資訊及timestamp。
這時候我們透過ip 192.168.69.9的機器來對其進行ping的動作:
可以看到封包全部都被drop掉了,但我們觀察xdpdump的視窗:
可以看到xdpdump仍然有秀出封包,證明這條datapath是開始於xdpfilter之前的,因此我們可以開始進行latency的實驗了,以下為實驗的拓樸:
整個datapath除了最底層開始打上timestamp的xdpdump,userspace也撰寫了接收封包並秀出最終timestamp的udp socket program,sender一樣使用ostinato產生udp封包。
先測試在什麼rule都不加的情況下,此條datapath的基準latency。
XDP timestamp | Userspace timestamp | Latency |
---|---|---|
1650830369.503261649 | 1650830369.6520882 | 149ms |
1650830374.659241607 | 1650830374.8080854 | 149ms |
1650830380.769574781 | 1650830380.918455 | 149ms |
1650830384.386681104 | 1650830384.5355697 | 149ms |
1650830387.134427942 | 1650830387.2833288 | 148.9ms |
因此基準值約為149ms。
接著我們安裝iptables,為其插入32個無用rule進行測試:
XDP timestamp | Userspace timestamp | Latency |
---|---|---|
1650831160.560912882 | 1650831161.1921768 | 632ms |
1650831164.396997172 | 1650831165.0282958 | 632ms |
1650831167.654823612 | 1650831168.286106 | 632ms |
1650831168.808675143 | 1650831169.4399452 | 631ms |
1650831169.872805632 | 1650831170.5040414 | 632ms |
約為632ms,可見iptables對於效能的影響十分顯著。
接下來我們分別測試32、64…256、512個無用rule對效能的影響。
可以看到,當rule數量上升對於latency的影響並不大。
再來我們測試xdpfilter對於latency的影響。先簡單開啟xdpfilter,將其load進driver,並加入一個簡單的ip rule。
XDP timestamp | Userspace timestamp | Latency |
---|---|---|
1650832552.789719874 | 1650832552.9692104 | 180ms |
1650832553.305622792 | 1650832553.4851184 | 179ms |
1650832553.897888837 | 1650832554.0774055 | 179ms |
1650832554.369722774 | 1650832554.5492766 | 180ms |
1650832554.883567726 | 1650832555.0630856 | 179ms |
latency約為179ms。接著試著同樣加入無用rule,測試xdpfilter的latency變化。
這是最後測試的結果,可以看到在500個rule的級距下,xdpfilter在latency上與iptables相比有顯著的提升。