<form id="xxt53"></form>
<form id="xxt53"><span id="xxt53"><th id="xxt53"></th></span></form>

<noframes id="xxt53"><address id="xxt53"></address>

    <em id="xxt53"><form id="xxt53"></form></em>

      <address id="xxt53"></address>

      新聞中心

      EEPW首頁 > 嵌入式系統 > 業界動態 > 使用 NVIDIA BlueField DPU 和 DPDK 開發應用程序

      使用 NVIDIA BlueField DPU 和 DPDK 開發應用程序

      作者:時間:2022-05-07來源:NVIDIA英偉達中國 收藏

      數據中心轉型

      本文引用地址:http://www.51kbu.com/article/202205/433848.htm

      BlueField (數據處理器)可用于網絡功能加速。這種網絡卸載可以用 DPDK ,也可以用 DOCA 軟件框架。

      在本系列中,我構建了一個應用并用兩種方式進行了卸載:DPDK 和 DOCA SDK 。我將每個步驟記錄為一個單獨的代碼補丁,并在每個系列中提供完整的步驟。這部分將向您展示如何用 DPDK 編程 BlueField 。

      用例

      首先,我需要一個簡單但有意義的用例來在 上部署應用程序。我選擇了基于策略的路由( PBR )來根據第 3 層和第 4 層數據包屬性將流量引導到不同的網關,覆蓋(或補充) X86 主機選擇的網關?,F實世界中有各種原因需要這樣做,包括以下示例:

      · 將選定主機流量發送到外部防火墻以進行額外審核

      · 增強 Anycast 服務器的負載平衡

      · 應用 QoS



      圖 1 . 使用 PBR 將流量從主機引導到兩個網關之一

      我在 DPU (BF2-ARM)上使用 PBR 將流量從主機( server1-x86 )引導到兩個網關 [leaf2, leaf3] 之一。葉交換機隨后將流量轉發給其本地連接的選播服務提供商 [server2, server3] 。

      構建應用程序

      第一個問題:我是寫一個全新的應用程序,還是卸載一個現有的應用程序?

      我決定卸載我最喜歡的開源路由軟件棧 FRRouting ( FRR )的 PBR 功能。這使我能夠擴展現有的代碼庫,并與現有的 sample apps 形成很好的對比。FRR 有一個支持多種數據平面插件的框架,可以輕松用 DPDK 和 DOCA 實現新的數據平面插件并集成到 FRR 。



      圖 2 . DPDK 和 DOCA 插件可以很容易地添加到 FRR中

      DPU 應用程序原型

      在本節中,我將介紹創建具有 DPU 硬件加速功能的應用程序所需的準備工作。

      DPU 硬件

      我有一個 x86 服務器并在上面安裝了一塊 BlueFied-2 DPU , 該 DPU 有兩個 25G 上行鏈路和一個帶有 8GB 內存的 ARM 處理器 。有關硬件安裝的更多信息,請參閱 DOCA SDK 文檔 。您也可以使用 DPU PocKit 來構建和引導你的系統環境.

      我安裝了 BlueField 啟動流文件( BFB ),它為 DPU 提供了 Ubuntu 操作系統映像,并附帶了 DOCA-1.2 和 DPDK-20.11.3 的庫。



      圖 3 . Netdev Representors

      使用 SR-IOV ,我在主機上為兩個虛擬機創建了兩個虛擬函數( VF )接口。

      主機上的 PF 和 VF 分別映射到 DPU ARM 上的以下 netdev representors 。



      表 1 .主機上 PF 和 VF 的映射

      使用 DPDK testpmd 應用程序進行原型設計

      首先,我使用 DPDK 的 testpmd 進行了我的用例的原型化設計,它位于 DPU 的 / opt / mellanox / 目錄下。

      包括 testpmd 在內的任何 DPDK 應用程序都必須設置 hugepages 。



      (可選)保留配置,使其在 DPU 重新啟動后仍然有效。



      啟動 testpmd 。



      Testpmd 會消耗比較多的內存,默認情況下會分配 3.5 GB 。由于我不需要在 CPU 中處理數據流量,我把 total-mem 的值設定為 200M ,其中 total-mem = total-num-mbufs * mbuf-size (默認 mbuf-size 為 2048 字節)。我還使用了 flow-isolation 模式,因為我必須將 ARP 數據包發送到 DPU 上的內核網絡堆棧來解析 PBR 的下一跳)。初始化完成后,-i選項使得 testpmd 進入交互式 shell 。

      作為 testpmd 完成 rte_eal 初始化的一部分, mlx5_pci 設備被探測并成為可以被訪問的 DPDK 端口。



      您在這里看到的 DPDK 端口對應 PF / VF representor 和兩個上行鏈路。



      表 2 . DPDK 端口映射

      流創建

      接下來,通過定義 ingress port 、源 IP 、目標 IP 、協議和端口,我用 rte_flow 下發了PBR規則。除此之外,我還定義了對匹配數據包采取的 ACTION 。源 MAC 和目標 MAC 被重寫, TTL 被遞減,出口端口被設置為物理上行鏈路 p0 。



      這條 PBR 規則從 VM1接收 DNS 流量,并將其發送到特定的 GW ( leaf2, server2 )。我還增加了一個計數器以便故障定位。



      DPU 卸載可以工作在 Switch ( FDB )模式,也可以工作在 NIC 模式。在這個用例中,經過幾次數據包修改后,我需要將流量從 X86 主機重定向到 25G 上行鏈路。所以從概念上講,這里使用了 Switch ( FDB ) 模式,因此需要設置 rte_flow 的 transfer 屬性。

      流程驗證

      我從 VM1 發送了一些流量,看看它是否與我用 testpmd 創建的 flow 是否匹配,可以通過執行 query 命令來查看。



      結果是匹配的,在 leaf2/server2 上可以看到這些流量且具有修改后的數據包頭。因為被操作的流量是 DNS ,所以為了測試流量,我從 VM1 發送 DNS 請求。為了控制流量速率和其他數據包字段,我使用 mz 來生成測試流量。



      另一個健全性檢查是查看此流是否真的被卸載。有兩種方法可以做到這一點:

      · 在 Arm CPU 上使用 tcpdump 以確保內核不接收此類數據包。

      · 檢查硬件 eSwitch 是否有對應的流規則。

      mlx_steering_dump 允許您查看硬件上已經下發成功的流規則。使用 git 下載并安裝該工具。



      使用 mlx_steering_dump_parser.py 腳本驗證硬件中下發的流規則。



      此命令打印出 testpmd 應用程序下發的所有流規則。我們可以看到硬件上設置的外部 頭匹配信息和前面RTE_FLOW定義的匹配 [SIP = 172.20.0.8 , DIP = 172.30.0.8 , IP proto = UDP , UDP dport = 53] 是一致的。作為打印輸出的一部分,流量計數器的值也被讀取并被重置。

      原型設計,作為應用程序設計思維過程的最后一步現在已經完成。我現在知道我可以在 DPDK 中建立一個 PBR 規則,把它安裝在硬件中并對我們感興趣的數據報文進行修改?,F在在下一節中添加 DPDK 數據平面。

      構建 DPDK 數據平面插件

      在本節中,我將通過向 Zebra 添加一個 DPDK 數據平面插件,介紹 DPU 對 PBR進行 硬件加速的步驟。我將這些步驟分解為單獨的代碼提交,整個補丁集以 reference 的形式提供。



      圖 4 .基于策略的路由 DPDK 卸載工作流

      開發環境

      由于目標體系結構是 DPU Arm ,因此可以直接在 DPU Arm上構建、在 X86 CPU 上交叉編譯或在云中構建。在這篇文章中,我直接在 DPU Arm 上進行編碼和構建。

      以 root 用戶身份運行應用程序

      FRR 通常作為非 root 用戶運行。FRR 可以下載和上傳整個互聯網路由表;這可能會出什么問題?然而,幾乎所有的 DPDK 應用程序都是以 root 用戶身份運行, DPDK 庫和驅動程序也都是基于這樣設計的。

      經過多次實驗,并使用 root 用戶選項重新編譯 FRR, 我還是無法讓 FRR 作為非 root 用戶工作。這是可以接受的,因為我在一個安全的空間,即 DPU Arm 中運行 FRR 。

      向 Zebra 添加新插件

      Zebra 是 FRR 中的一個守護進程,負責整合路由協議守護進程的更新并構建轉發表。Zebra 還有一個基礎設施,可以將這些轉發表推送到像 Linux 內核這樣的數據平面。

      將 DPDK 共享庫鏈接到 zebra

      FRR 有自己的構建系統,限制直接導入外部 make 文件。由于 pkg-config 的簡單優雅,將相關庫鏈接到 Zebra 很容易。

      我找到了 libdpdk.pc 并將其添加到 PKG_CONFIG_PATH 值中:



      FRR 有自己的構建系統,限制直接導入外部 make 文件。由于 pkg-config 的簡單優雅,將相關庫鏈接到 Zebra 很容易。

      我找到了 libdpdk.pc 并將其添加到 PKG_CONFIG_PATH 值中:



      我在 FRR makefile (configure.ac)中為 DPDK 添加了 pkg check-and-define 宏。



      我將 DPDK libs和cflags抽象包含在zebra-dp-dpdk make 宏( zebra/subdir.am )中。



      有了這些,我就有了構建插件所需的所有頭文件和庫。

      初始化硬件

      第一步是初始化硬件。



      這將探測 PCIe 設備并填充 DPDK rte_eth_dev 數據庫。

      初始化端口

      接下來設置硬件端口。

      設置應用程序的端口映射

      FRR 有自己的基于 Linux netdevs 表的接口(端口)表,該表使用 NetLink 更新填充,并使用 ifIndex 鍵值來索引。PBR 規則錨定到此表中的一個接口。要編程 PBR 數據平面條目,需要一個 Linux ifIndex 和 DPDK port-id 值之間的映射表。netdev 信息已經在 DPDK 驅動程序中可用,可以通過 rte_eth_dev_info_get 查詢。



      配置硬件端口

      此外,所有端口都需要置于 flow-isolation 模式并啟動。



      Flow-isolation 模式將未命中數據包發送到內核網絡堆棧,允許它處理 ARP 請求之類的事情。



      使用 rte _流 API 編程 PBR 規則

      PBR 規則現在需要用 rte_flow 來編寫,下面是一個示例規則:



      這些參數通過 rte_flow_attributes 、 rte_flow_item ( match ) 和 rte_flow_action 數據結構填充。

      流屬性

      此數據結構用于指示 PBR 流用于分組重定向或 transfer flow 。



      流匹配項

      DPDK 為數據包頭中的每一層使用 {key, mask} 匹配結構:以太網、 IP 、 UDP 等。



      填充這些數據結構需要大量重復的代碼。

      流動作

      DPDK 為每個 Action 使用單獨的數據結構,然后允許您在創建流規則時以可變長度數組的形式提供所有 Actions 。有關 Actions 如下:



      流驗證和創建

      作為可選項,您可以驗證 rte_flow_attr、rte_flow_item 和 rte_flow_action 列表。



      流驗證通常用于檢查底層 DPDK 驅動程序是否支持特定的流配置。流驗證是一個可選步驟,在最后的代碼中,您可以直接跳轉到流創建。



      Rte_flow 命令被錨定到輸入端口??梢詣摻ǘ鄠€流條目組并將這些組鏈起來。即使流條目不存在鏈的第一個組中,也就是不在組 0 中,它仍然必須錨定到輸入端口。group-0 存在性能限制。

      流量插入率在 group-0 中受到限制。要繞過該限制,您可以在 group-0 中安裝一個默認流,以“跳轉到 group-1 ”,然后在 group-1 中創建流規則。

      流刪除

      流創建 API 返回一個流指針,該指針必須被緩存以進行后續的流刪除。



      FRR-PBR 守護進程管理狀態機來解析,添加或刪除 PBR 流。因此,我不必使用 DPDK 的原生函數來老化 PBR 規則。

      流量統計

      在創建流時,我將計數操作附加到流??捎糜诓樵兞髁拷y計信息和命中次數。



      為了便于測試和驗證,我將該統計顯示插入了 FRR 的 vtysh CLI 。

      測試應用程序

      我以 root 用戶的身份啟動了 FRR ,并通過 /etc/frr/daemons 文件啟用了新添加的 DPDK 插件:

      DPDK-port 映射表的 FRR 接口已填充:



      接下來,我將 PBR 規則配置為匹配來自 VM1 的 DNS 流量,并使用 frr.conf 將其重定向到 leaf2 。



      我從 VM1 發送 DNS 查詢到 anycast DNS 服務器。



      匹配流,并使用修改后的數據包頭將流量轉發到目的地 leaf2/server2 。這可以通過連接到流的計數器和使用 mlx_steering_dump 做硬件轉儲來驗證。



      FRR 現在有一個功能齊全的 DPDK 數據平面插件,可以在 DPU 硬件上卸載 PBR 規則。

      總結

      這篇文章回顧了使用 DPDK RTE_FLOW庫在 BlueField 上硬件加速 PBR 規則的 FRR 數據平面插件的創建。在下一篇文章中,我將帶您了解 FRR DOCA 數據平面插件,并向您展示如何使用新的 DOCA_FLOW 庫卸載 PBR 規則。




      關鍵詞: DPU NVIDIA

      評論


      相關推薦

      技術專區

      關閉
      久热香蕉在线视频网站,日本A级特黄少妇大片,18videosex性欧美69中国
      <form id="xxt53"></form>
      <form id="xxt53"><span id="xxt53"><th id="xxt53"></th></span></form>

      <noframes id="xxt53"><address id="xxt53"></address>

        <em id="xxt53"><form id="xxt53"></form></em>

          <address id="xxt53"></address>