Devlink DPIPE¶

背景¶

在執行硬體解除安裝過程中，許多硬體細節無法呈現。這些細節對於除錯非常有用，devlink-dpipe 提供了一種標準化的方式來提供對解除安裝過程的可見性。

例如，Linux核心使用的路由最長字首匹配（LPM）演算法可能與硬體實現不同。管道除錯API（DPIPE）旨在以通用方式向用戶提供對ASIC管道的可見性。

硬體解除安裝過程應該以使用者無法區分硬體與軟體實現的方式進行。在這個過程中，硬體細節被忽略。實際上，這些細節可能具有很多意義，應該以某種標準方式公開。

當一個人希望將整個網路堆疊的控制路徑解除安裝到交換機ASIC時，這個問題變得更加複雜。由於硬體和軟體模型之間的差異，一些過程無法正確表示。

一個例子是核心的LPM演算法，在許多情況下，它與硬體實現有很大差異。配置API是相同的，但人們不能依賴轉發資訊庫（FIB）看起來像硬體中的Level Path Compression trie（LPC-trie）。

在許多情況下，僅基於核心轉儲來分析系統故障可能不夠。透過將此資料與有關底層硬體的補充資訊結合起來，可以使除錯更容易；此外，該資訊在除錯效能問題時可能很有用。

概述¶

devlink-dpipe 介面彌補了這個差距。硬體的管道被建模為匹配/動作表的圖。每個表代表一個特定的硬體塊。這種模型並不新鮮，首先被P4語言使用。

傳統上，它已被用作硬體配置的替代模型，但 devlink-dpipe 介面將其用於可見性目的，作為一種標準的補充工具。devlink-dpipe 中的系統檢視應根據標準配置工具所做的更改而更改。

例如，使用三態內容定址儲存器（TCAM）實現訪問控制列表（ACL）是很常見的。TCAM儲存器可以分為TCAM區域。複雜的TC過濾器可以有多個具有不同優先順序和不同查詢鍵的規則。另一方面，硬體TCAM區域具有預定義的查詢鍵。使用TCAM引擎解除安裝TC過濾器規則可能導致多個TCAM區域以鏈式方式互連（這可能會影響資料路徑延遲）。為了響應新的TC過濾器，應建立描述這些區域的新表。

模型¶

DPIPE 模型引入了幾個物件

頭部

表

條目

header 描述資料包格式，併為資料包中的欄位提供名稱。table 描述硬體塊。entry 描述特定表的實際內容。

硬體管道不是埠特定的，而是描述整個ASIC。因此，它與 devlink 基礎設施的頂部相關聯。

驅動程式可以在執行時註冊和登出表，以支援動態行為。這種動態行為對於描述像TCAM區域這樣的硬體塊是強制性的，TCAM區域可以動態分配和釋放。

devlink-dpipe 通常不用於配置。例外情況是特定表的硬體計數。

以下命令用於從使用者空間獲取 dpipe 物件

table_get：接收表的描述。

headers_get：接收裝置支援的頭部。

entries_get：接收表的當前條目。

counters_set：啟用或停用表上的計數器。

表¶

驅動程式應該為每個表實現以下操作

matches_dump：轉儲支援的匹配項。

actions_dump：轉儲支援的動作。

entries_dump：轉儲表的實際內容。

counters_set_update：同步硬體與啟用或停用的計數器。

頭部/欄位¶

以類似於 P4 的方式，頭部和欄位用於描述表的行為。標準協議頭部和特定 ASIC 元資料之間略有不同。協議頭部應在 devlink 核心 API 中宣告。另一方面，ASIC 元資料是驅動程式特定的，應在驅動程式中定義。此外，每個驅動程式特定的 devlink 文件檔案都應記錄它實現的驅動程式特定的 dpipe 頭部。頭部和欄位由列舉標識。

為了提供進一步的可見性，一些 ASIC 元資料欄位可以對映到核心物件。例如，內部路由器介面索引可以直接對映到網路裝置 ifindex。由不同虛擬路由和轉發（VRF）表使用的 FIB 表索引可以對映到內部路由表索引。

匹配¶

匹配保持原始狀態並接近硬體操作。由於這正是我們希望完整描述的過程，因此不支援像 LPM 這樣的匹配型別。匹配示例

field_exact：完全匹配特定欄位。

field_exact_mask：在遮蔽後完全匹配特定欄位。

field_range：匹配特定範圍。

為了識別特定欄位，應指定頭部和欄位的 ID。此外，應指定頭部索引，以便區分資料包中同一型別的多個頭部（隧道）。

動作¶

與匹配類似，動作保持原始狀態並接近硬體操作。例如

field_modify：修改欄位值。

field_inc：增加欄位值。

push_header：新增頭部。

pop_header：刪除頭部。

條目¶

可以根據需要轉儲特定表的條目。每個條目都由一個索引標識，其屬性由匹配/動作值和特定計數器的列表描述。透過轉儲表內容，可以解決表之間的互動。

抽象示例¶

以下是 Mellanox Spectrum ASIC 的 L3 部分的抽象模型示例。這些塊按照它們在管道中出現的順序描述。以下示例中的表大小不是實際的硬體大小，僅用於演示目的。

LPM¶

LPM 演算法可以實現為雜湊表列表。每個雜湊表包含具有相同字首長度的路由。列表的根是/32，如果未命中，硬體將繼續到下一個雜湊表。搜尋的深度將影響資料路徑延遲。

如果命中，該條目包含有關管道下一階段的資訊，該階段解析 MAC 地址。下一階段可以是直接連線路由的本地主機表，也可以是下一跳的鄰接表。meta.lpm_prefix 欄位用於連線兩個 LPM 表。

table lpm_prefix_16 {
  size: 4096,
  counters_enabled: true,
  match: { meta.vr_id: exact,
           ipv4.dst_addr: exact_mask,
           ipv6.dst_addr: exact_mask,
           meta.lpm_prefix: exact },
  action: { meta.adj_index: set,
            meta.adj_group_size: set,
            meta.rif_port: set,
            meta.lpm_prefix: set },
}

本地主機¶

在本地路由的情況下，LPM 查詢已經解析了出口路由器介面（RIF），但確切的 MAC 地址未知。本地主機表是一個雜湊表，它將輸出介面 ID 與目標 IP 地址組合作為鍵。結果是 MAC 地址。

table local_host {
  size: 4096,
  counters_enabled: true,
  match: { meta.rif_port: exact,
           ipv4.dst_addr: exact},
  action: { ethernet.daddr: set }
}

鄰接¶

在遠端路由的情況下，此表執行 ECMP。LPM 查詢導致 ECMP 組大小和索引，該索引用作此表中的全域性偏移量。同時，生成資料包的雜湊。基於 ECMP 組大小和資料包的雜湊，生成本地偏移量。多個 LPM 條目可以指向同一個鄰接組。

table adjacency {
  size: 4096,
  counters_enabled: true,
  match: { meta.adj_index: exact,
           meta.adj_group_size: exact,
           meta.packet_hash_index: exact },
  action: { ethernet.daddr: set,
            meta.erif: set }
}

ERIF¶

如果出口 RIF 和目標 MAC 已被先前的表解析，則此表執行多個操作，例如 TTL 減少和 MTU 檢查。然後做出轉發/丟棄的決定，並根據資料包的型別（廣播、單播、多播）更新埠 L3 統計資訊。

table erif {
  size: 800,
  counters_enabled: true,
  match: { meta.rif_port: exact,
           meta.is_l3_unicast: exact,
           meta.is_l3_broadcast: exact,
           meta.is_l3_multicast, exact },
  action: { meta.l3_drop: set,
            meta.l3_forward: set }
}

Linux核心

目錄

本頁