引言

Intel新的SKYLAKE微處理架構自15年釋出至今，已經相對成熟可以進入商用階段，最近很多供貨商也都在積極推廣；公司之前用的主要都是Sandy bridge架構，18年據說也要停產了，所以需要考慮升級相關事宜。從供貨商那邊選了兩款樣機，準備詳細測試下網路效能，是否有針對之前架構有效能提升，及提升效能能到多少。

本文主要記錄下測試方法，以及測試過程中遇到的問題和解決步驟，具體的測試對比結果只在內部開放，請諒解。

理論知識

Intel Skylake是英特爾第六代微處理器架構，採用14納米制程，是Intel Haswell微架構及其製程改進版Intel Broadwell微架構的繼任者， 提供更高的CPU和GPU效能並有效減少電源消耗。
主要特性包括：

- 14納米制程，6th Gen processor
- 同時支援DDR3L和DDR4-SDRAM兩種記憶體規格，最高支援64GB；
- PCIE支援3.0，速度最高支援8GT/s;
- 去掉了Haswell引入的FIVR，使用分離的PCH，DMI3.0

測試拓撲及環境準備

專案	描述
作業系統	linux，核心2.6.X （影響不大）
CPU	Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
記憶體	32GB
網絡卡晶片	intel x710，4口10G
dpdk版本	dpdk-16.04
測試程式	l2fwd,l3fwd
測試套件	Spirent RFC 2544套件

使用dpdk sample程式前需要做一些初始化動作，載入對應的module、驅動，配置對應的大頁記憶體等，寫了個初始化指令碼如下：

#!/bin/bash
mount -t hugetlbfs nodev /mnt/huge
#set hugepage memory
echo 1024 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

#add kernel module
modprobe uio
insmod /root/dpdk-16.04
 
/x86_64-native-linuxapp-gcc/kmod/igb_uio.ko

#down interfaces to disable routes
#ifconfig eth0 down

#display netcard driver before bind
/root/dpdk-16.04/tools/dpdk_nic_bind.py -s

#bind driver
/root/dpdk-16.04/tools/dpdk_nic_bind.py -b igb_uio 0000:01:00.0
/root/dpdk-16.04/tools/dpdk_nic_bind.py -b igb_uio 0000:01:00.1
/root/dpdk-16.04/tools/dpdk_nic_bind.py -b igb_uio 0000:01:00.2
/root/dpdk-16.04/tools/dpdk_nic_bind.py -b igb_uio 0000:01:00.3

#display netcard driver after bind
/root/dpdk-16.04/tools/dpdk_nic_bind.py -s

具體的測試拓撲如下：

測試過程及問題解決

由於dpdk的sample執行時需要手動繫結埠和CPU核的關係，所以在執行前最好能瞭解當前的核分佈情況：

root>python cpu_layout.py 
============================================================
Core and Socket Information (as reported by '/proc/cpuinfo')
============================================================

cores =  [0, 1, 2, 3]
sockets =  [0]

       Socket 0      
       --------      
Core 0 [0, 4]        
Core 1 [1, 5]        
Core 2 [2, 6]        
Core 3 [3, 7]       

可以看出cpu有一個物理核，4個邏輯核，已經開啟了超執行緒。

一個口自收自發

先測試最簡單的情況，一個口自收自發，看能否達到線速。

1. 使用l2fwd測試，1口1佇列

l2fwd -c0xf -n4 -- -p0x1 

測試結果（兩組資料，後面的效果更好但沒測全，但都無法達到線速）：

1. 使用l2fwd測試，1口4佇列(標準的l2fwd不支援，需要修改程式碼支援)

l2fwd -c0xf -n4 -- -p0x1 -q4 

測試結果：

理論上應該還能提升的，待進一步優化。

1. 使用l3fwd測試，1口1佇列
   命令如下：

l3fwd -l 0  -n4 -- -p1 -P --config="(0,0,0)"

測試結果：

1. 使用l3fwd測試，1口2佇列
   命令如下：

./l3fwd -l 0,1 -n4 -- -p1 -P --config="(0,0,0)(0,1,1)"

使用lcore 0,1， 埠1兩個佇列，每個佇列繫結一個lcore
測試結果：

結論：效能瓶頸和每個埠上的佇列有關係，和CPU基本沒關係。當使用l3fwd測試時，小包可以達到限速。使用l2fwd測試時，標準版本效果不是特別滿意，估計還是l2fwd的單佇列和轉發模型太過簡單。

兩個口互相轉發

接著測試兩個口互相轉發，看能否限速轉發。

直接測試最優的情況，使用l3fwd每個埠2佇列

./l3fwd -l 0,1,2,3 -n4 -- -p0xf -P --config="(0,0,0)(0,1,1)(1,0,2)(1,1,3)"

測試結果：

在這個測試過程中遇到一個問題，兩個完全相同的平臺，一個平臺64位元組可以線速轉發，另外一個只能到9%左右，如下圖：

排查思路：
1. 首先確定介面繫結是否正確，測試的軟體版本等是否一致。
2. 檢視網絡卡晶片的引數，確保使用PCI3 Gen3 x8 or Gen3 x16

lspci -s 01:00.1 -vv | grep LnkSta
        LnkSta: Speed 8GT/s, Width x4, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
        LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, 

本次排查過程中發現出問題的網絡卡width引數為x4, 正常的網絡卡引數為x8. 這塊需要重點跟蹤下，x4的通道直接就減半了，通過和廠家溝通主機板上拉出的通道是支援x8的，可能的原因是網絡卡金手指上貼了膠帶，經過排查果然如此，之前測試x4的插槽時，做了相關動作。

3. 網絡卡引數正常後，發現測試結果仍然無法達到另外一個平臺測試的理想結果，此時可以檢視l3fwd的啟動日誌，看看網口啟動選擇rx和tx函式是否一致：
發現正常的平臺log資訊如下：

Initializing rx queues on lcore 4 ... rxq=1,1,0 PMD: check_rx_burst_bulk_alloc_preconditions(): Rx Burst Bulk Alloc Preconditions: rxq->nb_rx_desc=4096, I40E_MAX_RING_DESC=4096, RTE_PMD_I40E_RX_MAX_BURST=32
PMD: check_rx_burst_bulk_alloc_preconditions(): Rx Burst Bulk Alloc Preconditions: rxq->nb_rx_desc=4096, I40E_MAX_RING_DESC=4096, RTE_PMD_I40E_RX_MAX_BURST=32
PMD: i40e_dev_rx_queue_setup(): Rx Burst Bulk Alloc Preconditions are not satisfied, Scattered Rx is requested, or RTE_LIBRTE_I40E_RX_ALLOW_BULK_ALLOC is not enabled on port=1, queue=1.

PMD: i40e_set_tx_function(): Vector tx finally be used.
PMD: i40e_pf_config_rss(): Max of contiguous 2 PF queues are configured
PMD: i40e_set_rx_function(): Port[0] doesn't meet Vector Rx preconditions
PMD: i40e_set_rx_function(): Rx Burst Bulk Alloc Preconditions are not satisfied, or Scattered Rx is requested (port=0).
PMD: i40e_set_tx_function(): Vector tx finally be used.
PMD: i40e_pf_config_rss(): Max of contiguous 2 PF queues are configured
PMD: i40e_set_rx_function(): Port[1] doesn't meet Vector Rx preconditions
PMD: i40e_set_rx_function(): Rx Burst Bulk Alloc Preconditions are not satisfied, or Scattered Rx is requested (port=1).

而異常的平臺log資訊如下：

Initializing rx queues on lcore 0 ... rxq=0,0,0 PMD: i40e_dev_rx_queue_setup(): Rx Burst Bulk Alloc Preconditions are satisfied. Rx Burst Bulk Alloc function will be used on port=0, queue=0.

Initializing rx queues on lcore 1 ... rxq=0,1,0 PMD: i40e_dev_rx_queue_setup(): Rx Burst Bulk Alloc Preconditions are satisfied. Rx Burst Bulk Alloc function will be used on port=0, queue=1.

Initializing rx queues on lcore 2 ... rxq=1,0,0 PMD: i40e_dev_rx_queue_setup(): Rx Burst Bulk Alloc Preconditions are satisfied. Rx Burst Bulk Alloc function will be used on port=1, queue=0.

Initializing rx queues on lcore 3 ... rxq=1,1,0 PMD: i40e_dev_rx_queue_setup(): Rx Burst Bulk Alloc Preconditions are satisfied. Rx Burst Bulk Alloc function will be used on port=1, queue=1.

PMD: i40e_set_tx_function(): Vector tx finally be used.
PMD: i40e_pf_config_rss(): Max of contiguous 2 PF queues are configured
PMD: i40e_set_rx_function(): Port[0] doesn't meet Vector Rx preconditions
PMD: i40e_set_rx_function(): Rx Burst Bulk Alloc Preconditions are satisfied. Rx Burst Bulk Alloc function will be used on port=0.
PMD: i40e_set_tx_function(): Vector tx finally be used.
PMD: i40e_pf_config_rss(): Max of contiguous 2 PF queues are configured
PMD: i40e_set_rx_function(): Port[1] doesn't meet Vector Rx preconditions
PMD: i40e_set_rx_function(): Rx Burst Bulk Alloc Preconditions are satisfied. Rx Burst Bulk Alloc function will be used on port=1.

可以看出應該是nb_rx_desc 和 nb_tx_desc的設定不一樣導致的rx模式選擇不一樣，正常的選擇的是rx_recv_pkts，異常的選擇的是i40e_recv_pkts_bulk_alloc。現修改成一致的，測試通過。

結論：2埠互相轉發，64位元組也能達到線速轉發；存疑點：Burst模式應該是優於普通模式的，但實際的測試結果卻不是，應該有優化選項沒設定對，後續還要跟蹤下。

四個口互相轉發

接著測試四口相互轉發，重點關注小包是否能夠線速

測試命令：
1. 每個口一個佇列，一個核：

./l3fwd -l 0,1,2,3 -n4 -- -p0xf -P --config="(0,0,0)(1,0,1)(2,0,2)(3,0,3)"

測試結果：


兩個平臺測試引數略有差異，最高也就到53%~55%左右。
2. 使用超執行緒，每個口兩個佇列，每個佇列一個核

l3fwd -l 0,1,2,3,4,5,6,7 -n4 -- -p0xf -P --config="(0,0,0)(0,1,1)(1,0,2)(1,1,3)(2,0,4)(2,1,5)(3,0,6)(3,1,7)"

測試結果：

1. 使用超執行緒，每個口兩個佇列，每個口一個核

./l3fwd -l 0,1,2,3,4,5,6,7 -n4 -- -p0xf -P --config="(0,0,0)(0,1,0)(1,0,1)(1,1,1)(2,0,2)(2,1,2)(3,0,3)(3,1,3)"

測試結果：

而此時cpu的利用情況如下：

結論：4個口小包無法達到線速轉發，此時CPU已經滿負載（瓶頸所在），256位元組之後可以。另外，發現開啟超執行緒對效能沒有太大提升，如果核的分配出現競爭的情況（如最後一次測試），效能反而會下降。

總結

以上是完整的測試過程，以及測試過程中遇到和解決問題的思路，希望能對大家有益。 關於l2fwd測試的效率低下這塊，後續還會再修改程式碼繼續研究，如果有成果，再和大家分享。

備註

csdn的markdown編輯器中關於有序列表部分真的讓人頭痛，copy過來還得重新編輯還不一定好使，大家湊合看吧。