架構

本文件介紹了分散式交換機架構 (DSA) 子系統的設計原則、侷限性、與其他子系統的互動，以及如何為此子系統開發驅動程式，以及有興趣參與此項工作的開發人員的 TODO。

設計原則

分散式交換機架構子系統最初設計用於支援 Marvell 乙太網交換機（MV88E6xxx，也稱為 Link Street 產品線），使用 Linux，但後來發展為支援其他供應商。

此設計背後的最初理念是能夠使用未修改的 Linux 工具（例如 bridge、iproute2、ifconfig）來透明地工作，無論它們是配置/查詢交換機埠網路裝置還是常規網路裝置。

乙太網交換機通常包含多個前面板埠以及一個或多個 CPU 或管理埠。DSA 子系統當前依賴於連線到乙太網控制器的管理埠的存在，該控制器能夠從交換機接收乙太網幀。這是在小型家庭和辦公室產品（路由器、閘道器，甚至是架頂式交換機）中發現的各種乙太網交換機的一種非常常見的設定。此主機乙太網控制器將在 DSA 術語和程式碼中稍後被稱為“導管 (conduit)”和“cpu”。

DSA 中的 D 代表分散式，因為該子系統被設計為能夠使用交換機之間的上游和下游乙太網鏈路來配置和管理彼此之上的級聯交換機。這些特定埠在 DSA 術語和程式碼中被稱為“dsa”埠。連線在一起的多個交換機的集合稱為“交換機樹”。

對於每個前面板埠，DSA 建立專門的網路裝置，這些裝置用作 Linux 網路堆疊使用的控制和資料流端點。這些專門的網路介面在 DSA 術語和程式碼中被稱為“使用者 (user)”網路介面。

使用 DSA 的理想情況是當乙太網交換機支援“交換機標籤 (switch tag)”時，這是一種硬體功能，使交換機為它接收的每個乙太網幀插入一個特定的標籤，以幫助管理介面確定

  • 此幀來自哪個埠

  • 此幀被轉發的原因是什麼

  • 如何將 CPU 發起的流量傳送到特定埠

該子系統確實支援無法插入/剝離標籤的交換機，但在這種情況下，功能可能會受到一些限制（流量分離依賴於基於埠的 VLAN ID）。

請注意，DSA 當前不為“cpu”和“dsa”埠建立網路介面，因為

  • “cpu”埠是管理控制器的乙太網交換機側，因此會建立功能重複，因為您會獲得兩個介面用於同一導管：導管 netdev 和“cpu” netdev

  • “dsa”埠只是兩個或多個交換機之間的導管，因此也不能真正用作適當的網路介面，只有下游或最頂端的上游接口才符合該模型

注意：在過去的 15 年裡，DSA 子系統一直在使用術語“主 (master)”（而不是“導管 (conduit)”）和“從 (slave)”（而不是“使用者 (user)”）。這些術語已從 DSA 程式碼庫中刪除，並在 uAPI 中逐步淘汰。

交換機標記協議

DSA 支援許多供應商特定的標記協議、一種軟體定義的標記協議以及一種無標記模式 (DSA_TAG_PROTO_NONE)。

標籤協議的確切格式是供應商特定的，但通常，它們都包含一些東西

  • 標識乙太網幀來自/應傳送到哪個埠

  • 提供將此幀轉發到管理介面的原因

所有標記協議都在 net/dsa/tag_*.c 檔案中，並實現 struct dsa_device_ops 結構的方法，如下所述。

標記協議通常分為以下三類之一

  1. 特定於交換機的幀頭位於乙太網頭之前，從 DSA 導管的幀解析器的角度來看，向右移動了 MAC DA、MAC SA、EtherType 和整個 L2 有效負載。

  2. 特定於交換機的幀頭位於 EtherType 之前，從 DSA 導管的角度來看，保持 MAC DA 和 MAC SA 不變，但將“真實”的 EtherType 和 L2 有效負載向右移動。

  3. 特定於交換機的幀頭位於資料包的尾部，保持所有幀頭不變，並且不改變 DSA 導管的幀解析器擁有的資料包檢視。

標記協議可以使用相同長度的交換機標籤標記所有資料包，或者標籤長度可能會有所不同（例如，帶有 PTP 時間戳的資料包可能需要擴充套件的交換機標籤，或者 TX 上可能有一個標籤長度，而 RX 上有不同的標籤長度）。無論哪種方式，標記協議驅動程式都必須使用最長的交換機幀頭/尾的八位位元組長度填充 struct dsa_device_ops::needed_headroom 和/或 struct dsa_device_ops::needed_tailroom。DSA 框架將自動調整導管介面的 MTU 以適應此額外大小，以便 DSA 使用者埠支援 1500 八位位元組的標準 MTU（L2 有效負載長度）。needed_headroom 和 needed_tailroom 屬性還用於在盡力而為的基礎上向網路堆疊請求分配具有足夠額外空間的包，以便在傳輸包時推送交換機標籤的行為不會由於記憶體不足而導致其重新分配。

即使不希望應用程式解析 DSA 特定的幀頭，標記協議在線上的格式也表示核心向用戶空間公開的應用程式二進位制介面，用於 libpcap 等解碼器。標記協議驅動程式必須使用唯一描述交換機硬體和資料路徑驅動程式之間所需互動特徵的值來填充 struct dsa_device_ops 的 proto 成員：幀頭中每個位欄位的偏移量以及處理幀所需的任何有狀態處理（PTP 時間戳可能需要）。

從網路堆疊的角度來看，同一 DSA 交換機樹中的所有交換機都使用相同的標記協議。如果資料包透過具有多個交換機的結構傳輸，則交換機特定的幀頭由資料包接收到的結構中的第一個交換機插入。此標頭通常包含有關其型別的資訊（它是必須捕獲到 CPU 的控制幀，還是要轉發的資料幀）。控制幀應僅由軟體資料路徑解封裝，而資料幀也可以自主轉發到同一結構中其他交換機的其他使用者埠，在這種情況下，最外層的交換機埠必須解封裝資料包。

請注意，在某些情況下，葉子交換機（未直接連線到 CPU）使用的標記格式可能與網路堆疊看到的格式不同。這可以在 Marvell 交換機樹中看到，其中 CPU 埠可以配置為使用 DSA 或 Ethertype DSA (EDSA) 格式，但 DSA 鏈路配置為使用較短的（沒有 Ethertype）DSA 幀頭，以便減少自主資料包轉發開銷。如果 DSA 交換機樹配置為 EDSA 標記協議，作業系統仍然可以看到來自使用較短的 DSA 標頭標記它們的葉子交換機的 EDSA 標記資料包。這樣做是因為連線到 CPU 的 Marvell 交換機配置為在 DSA 和 EDSA 之間執行標籤轉換（這只是新增或刪除 ETH_P_EDSA EtherType 和一些填充八位位元組的操作）。

即使 DSA 交換機的標記協議彼此不相容，也可以構建 DSA 交換機的級聯設定。在這種情況下，此結構中沒有 DSA 鏈路，並且每個交換機都構成一個不相交的 DSA 交換機樹。DSA 鏈路被視為只是一對 DSA 導管（上游 DSA 交換機的面向外的埠）和一個 CPU 埠（下游 DSA 交換機的面向內的埠）。

可以透過 DSA 導管的 dsa/tagging sysfs 屬性檢視附加的 DSA 交換機樹的標記協議

cat /sys/class/net/eth0/dsa/tagging

如果硬體和驅動程式能夠做到，則可以在執行時更改 DSA 交換機樹的標記協議。這是透過將新的標記協議名稱寫入與上述相同的 sysfs 裝置屬性來完成的（執行此操作時，DSA 導管和所有附加的交換機埠都必須關閉）。

希望所有標記協議都可以使用 dsa_loop 模擬驅動程式進行測試，該驅動程式可以附加到任何網路介面。目標是任何網路介面都應該能夠以相同的方式傳輸相同的包，並且標記器應該以相同的方式解碼相同的接收包，而不管用於交換機控制路徑的驅動程式以及用於 DSA 導管的驅動程式如何。

資料包的傳輸透過標記器的 xmit 函式進行。傳遞的 struct sk_buff *skb 的 skb->data 指向 skb_mac_header(skb)，即目標 MAC 地址，並且傳遞的 struct net_device *dev 表示必須將資料包轉向的虛擬 DSA 使用者網路介面的硬體對應物（即 swp0）。此方法的工作是以一種交換機可以理解資料包的目標出口埠的方式來準備 skb（並且不要將其傳遞到其他埠）。通常，這是透過推送幀頭來實現的。如果 needed_headroom 和 needed_tailroom 屬性已正確填充，則無需檢查 skb 頭部空間或尾部空間中是否有足夠的空間，因為 DSA 確保在呼叫此方法之前有足夠的空間。

資料包的接收透過標記器的 rcv 函式進行。傳遞的 struct sk_buff *skb 的 skb->data 指向 skb_mac_header(skb) + ETH_ALEN 八位位元組，即，如果沒有標記此幀，則指向 EtherType 之後的第一個八位位元組的位置。此方法的作用是消耗幀頭，調整 skb->data 以真正指向 EtherType 之後的第一個八位位元組，並將 skb->dev 更改為指向與接收資料包的物理面向前的交換機埠相對應的虛擬 DSA 使用者網路介面。

由於第 1 類和第 2 類中的標記協議會破壞 DSA 導管上的軟體（並且通常也破壞硬體）資料包剖析，因此 DSA 導管上的 RPS（接收資料包轉向）等功能將被破壞。DSA 框架透過掛接到流剖析器並移動 IP 標頭在 DSA 導管看到的標記幀中找到的偏移量來處理此問題。此行為基於標記協議的 overhead 值自動進行。如果並非所有資料包的大小都相同，則標記器可以實現 struct dsa_device_ops 的 flow_dissect 方法，並透過指定每個單獨的 RX 資料包產生的正確偏移量來覆蓋此預設行為。尾部標記器不會給流剖析器帶來問題。

當 DSA 導管驅動程式在 vlan_features 中宣告 NETIF_F_HW_CSUM 並檢視 csum_start 和 csum_offset 時，校驗和解除安裝應與第 1 類和第 2 類標記器一起使用。對於這些情況，DSA 將按標籤大小移動校驗和開始和偏移量。如果 DSA 導管驅動程式仍在 vlan_features 中使用舊版 NETIF_F_IP_CSUM 或 NETIF_F_IPV6_CSUM，則僅當解除安裝硬體已經期望該特定標籤時，解除安裝才可能起作用（可能是由於匹配的供應商）。DSA 使用者埠從導管繼承這些標誌，並且驅動程式有責任在 IP 標頭不在硬體期望的位置時正確回退到軟體校驗和。如果該檢查無效，則資料包可能會在沒有適當校驗和的情況下進入網路（校驗和欄位將具有偽 IP 標頭總和）。對於第 3 類，當解除安裝硬體尚未期望使用的交換機標籤時，必須在插入任何標籤之前計算校驗和（即在標記器內部）。否則，DSA 導管會將尾部標籤包含在（軟體或硬體）校驗和計算中。然後，當標籤在傳輸過程中被交換機剝離時，它將留下不正確的 IP 校驗和。

由於各種原因（最常見的是第 1 類標記器與 DSA 不感知的導管相關聯，從而破壞了導管感知到的 MAC DA），標記協議可能要求 DSA 導管以混雜模式執行，以接收所有幀，而不管 MAC DA 的值如何。這可以透過設定 struct dsa_device_ops 的 promisc_on_conduit 屬性來完成。請注意，這假設 DSA 不感知的導管驅動程式，這是常態。

導管網路裝置

導管網路裝置是用於 CPU/管理乙太網介面的常規、未修改的 Linux 網路裝置驅動程式。這樣的驅動程式可能偶爾需要知道是否啟用了 DSA（例如：啟用/停用特定的解除安裝功能），但是 DSA 子系統已被證明可以與行業標準驅動程式一起使用：e1000e、 mv643xx_eth 等，而無需對這些驅動程式進行修改。此類網路裝置通常也稱為導管網路裝置，因為它們充當主機處理器和硬體乙太網交換機之間的管道。

網路堆疊掛鉤

當導管 netdev 與 DSA 一起使用時，會在網路堆疊中放置一個小的掛鉤，以便讓 DSA 子系統處理乙太網交換機特定的標記協議。DSA 透過向網路堆疊註冊特定的（和偽造的）乙太網型別（後來變為 skb->protocol）來實現此目的，這也被稱為 ptype 或 packet_type。典型的乙太網幀接收序列如下所示

導管網路裝置（例如：e1000e）

  1. 接收中斷觸發

    • 呼叫接收函式

    • 完成基本的資料包處理：獲取長度、狀態等。

    • 透過呼叫 eth_type_trans 準備資料包以供乙太網層處理

  2. net/ethernet/eth.c

    eth_type_trans(skb, dev)
        if (dev->dsa_ptr != NULL)
                -> skb->protocol = ETH_P_XDSA

  3. drivers/net/ethernet/*

    netif_receive_skb(skb)
        -> iterate over registered packet_type
                -> invoke handler for ETH_P_XDSA, calls dsa_switch_rcv()

  4. net/dsa/dsa.c

    -> dsa_switch_rcv()
        -> invoke switch tag specific protocol handler in 'net/dsa/tag_*.c'

  5. net/dsa/tag_*.c

    • 檢查並剝離交換機標籤協議以確定始發端口

    • 找到每個埠的網路裝置

    • 使用 DSA 使用者網路裝置呼叫 eth_type_trans()

    • 呼叫 netif_receive_skb()

在此之後，DSA 使用者網路裝置會收到可以由網路堆疊處理的常規乙太網幀。

使用者網路裝置

DSA 建立的使用者網路裝置堆疊在其導管網路裝置之上，這些網路介面中的每一個都將負責作為交換機每個前面板埠的控制和資料流端點。這些介面專門用於

  • 在將流量傳送到/從特定交換機埠傳送流量時插入/刪除交換機標籤協議（如果存在）

  • 查詢交換機的 ethtool 操作：統計資訊、鏈路狀態、Wake-on-LAN、暫存器轉儲...

  • 管理外部/內部 PHY：鏈路、自動協商等。

這些使用者網路裝置具有自定義的 net_device_ops 和 ethtool_ops 函式指標，這些指標允許 DSA 在網路堆疊/ethtool 和交換機驅動程式實現之間引入一個層次。

在從這些使用者網路裝置傳輸幀時，DSA 將查詢當前已向這些網路設備註冊的交換機標記協議，並呼叫特定的傳輸例程，該例程負責在乙太網幀中新增相關的交換機標籤。

然後使用導管網路裝置 ndo_start_xmit() 函式將這些幀排隊以進行傳輸。由於它們包含適當的交換機標籤，因此乙太網交換機將能夠處理來自管理介面的這些傳入幀並將它們傳遞到物理交換機埠。

當使用多個 CPU 埠時，可以在 DSA 使用者裝置和物理 DSA 導管之間堆疊 LAG（繫結/團隊）裝置。因此，LAG 裝置也是 DSA 導管，但 LAG 從屬裝置也繼續是 DSA 導管（只是沒有分配給它們的使用者埠；如果 LAG DSA 導管消失，則需要這樣做以進行恢復）。因此，LAG DSA 導管的資料路徑是不對稱使用的。在 RX 上，ETH_P_XDSA 處理程式（呼叫 dsa_switch_rcv()）會被提前呼叫（在物理 DSA 導管；LAG 從屬裝置上）。因此，未使用 LAG DSA 導管的 RX 資料路徑。另一方面，TX 線性發生：dsa_user_xmit 呼叫 dsa_enqueue_skb，後者呼叫指向 LAG DSA 導管的 dev_queue_xmit。後者呼叫指向一個或另一個物理 DSA 導管的 dev_queue_xmit，在這兩種情況下，資料包都透過通向交換機的硬體路徑退出系統。

圖形表示

總而言之，這基本上就是從網路裝置角度來看 DSA 的樣子

             Unaware application
           opens and binds socket
                    |  ^
                    |  |
        +-----------v--|--------------------+
        |+------+ +------+ +------+ +------+|
        || swp0 | | swp1 | | swp2 | | swp3 ||
        |+------+-+------+-+------+-+------+|
        |          DSA switch driver        |
        +-----------------------------------+
                      |        ^
         Tag added by |        | Tag consumed by
        switch driver |        | switch driver
                      v        |
        +-----------------------------------+
        | Unmodified host interface driver  | Software
--------+-----------------------------------+------------
        |       Host interface (eth0)       | Hardware
        +-----------------------------------+
                      |        ^
      Tag consumed by |        | Tag added by
      switch hardware |        | switch hardware
                      v        |
        +-----------------------------------+
        |               Switch              |
        |+------+ +------+ +------+ +------+|
        || swp0 | | swp1 | | swp2 | | swp3 ||
        ++------+-+------+-+------+-+------++

使用者 MDIO 匯流排

為了能夠讀取和寫入內置於交換機中的 PHY，DSA 建立了一個使用者 MDIO 匯流排，該匯流排允許特定的交換機驅動程式分流和攔截對特定 PHY 地址的 MDIO 讀取/寫入。在大多數 MDIO 連線的交換機中，這些函式將利用直接或間接 PHY 定址模式從交換機內建 PHY 返回標準 MII 暫存器，從而允許 PHY 庫和/或返回鏈路狀態、鏈路夥伴頁面、自動協商結果等。

對於同時具有外部和內部 MDIO 匯流排的乙太網交換機，使用者 MII 匯流排可用於將 MDIO 讀取和寫入多路複用/解多路複用到此交換機可能連線到的內部或外部 MDIO 裝置：內部 PHY、外部 PHY 甚至外部交換機。

資料結構

DSA 資料結構在 include/net/dsa.h 以及 net/dsa/dsa_priv.h 中定義

  • dsa_chip_data：給定交換機裝置的平臺數據配置，此結構描述了交換機裝置的父裝置、其地址以及其埠的各種屬性：名稱/標籤，最後是路由表指示（當級聯交換機時）

  • dsa_platform_data：平臺裝置配置資料，如果級聯了多個交換機，則可以引用 dsa_chip_data 結構的集合，需要引用此交換機樹所連線到的導管網路裝置

  • dsa_switch_tree：在 dsa_ptr 下分配給導管網路裝置的結構，此結構引用 dsa_platform_data 結構以及交換機樹支援的標記協議，以及應呼叫的接收/傳輸函式掛鉤、還提供了有關直接連線的交換機的資訊：CPU 埠。最後，引用 dsa_switch 的集合以定址樹中的各個交換機。

  • dsa_switch：描述樹中交換機裝置的結構，引用 dsa_switch_tree 作為反向指標、使用者網路裝置、導管網路裝置，並引用後備``dsa_switch_ops``

  • dsa_switch_ops：引用函式指標的結構，有關完整說明，請參見下文。

設計限制

缺少 CPU/DSA 網路裝置

如前所述，DSA 當前不為 CPU 或 DSA 埠建立使用者網路裝置。在以下情況下，這可能是一個問題

  • 無法使用 ethtool 獲取交換機 CPU 埠統計資訊計數器，這會使除錯使用 xMII 介面連線的 MDIO 交換機更加困難

  • 無法根據連線到它的乙太網控制器的功能配置 CPU 埠鏈路引數：http://patchwork.ozlabs.org/patch/509806/

  • 在使用級聯設定時，無法配置交換機之間的特定 VLAN ID / 中繼 VLAN

使用 DSA 設定的常見陷阱

一旦配置導管網路裝置以使用 DSA（dev->dsa_ptr 變為非 NULL），並且它後面的交換機期望標記協議，則此網路介面只能專門用作導管介面。直接透過此介面傳送資料包（例如：使用此介面開啟套接字）不會使我們透過交換機標記協議傳輸函式，因此另一端的乙太網交換機期望標籤通常會丟棄此幀。

與其他子系統的互動

DSA 當前利用以下子系統

  • MDIO/PHY 庫：drivers/net/phy/phy.c、mdio_bus.c

  • Switchdev：net/switchdev/*

  • 裝置樹用於各種 of_* 函式

  • Devlink：net/core/devlink.c

MDIO/PHY 庫

DSA 公開的使用者網路裝置可能會或可能不會與 PHY 裝置 (struct phy_device（如 include/linux/phy.h) 中定義）連線，但是 DSA 子系統處理所有可能的組合

  • 內置於乙太網交換機硬體中的內部 PHY 裝置

  • 透過內部或外部 MDIO 匯流排連線的外部 PHY 裝置

  • 透過內部 MDIO 匯流排連線的內部 PHY 裝置

  • 特殊的、非自動協商或非 MDIO 管理的 PHY 裝置：SFP、MoCA；又名固定 PHY

PHY 配置由 dsa_user_phy_setup() 函式完成，其邏輯基本上如下所示

  • 如果使用裝置樹，則使用標準的“phy-handle”屬性查詢 PHY 裝置，如果找到，則使用 of_phy_connect() 建立並註冊此 PHY 裝置

  • 如果使用裝置樹，並且 PHY 裝置是“固定的”，也就是說，符合 Documentation/devicetree/bindings/net/fixed-link.txt 中定義的非 MDIO 管理的 PHY 的定義，則使用特殊的固定 MDIO 匯流排驅動程式透明地註冊和連線 PHY

  • 最後，如果 PHY 內置於交換機中，這在獨立交換機包中非常常見，則使用 DSA 建立的使用者 MII 匯流排探測 PHY

SWITCHDEV

在與橋接層連線時，DSA 直接利用 SWITCHDEV，更具體地說，在透過每個埠的使用者網路裝置配置 VLAN 時，利用其 VLAN 過濾部分。到目前為止，DSA 支援的唯一 SWITCHDEV 物件是 FDB 和 VLAN 物件。

裝置樹

DSA 具有標準化的繫結，文件位於 Documentation/devicetree/bindings/net/dsa/dsa.txt。PHY/MDIO 庫輔助函式（如 of_get_phy_mode()、of_phy_connect()）也用於查詢每個埠的 PHY 特定詳細資訊：介面連線、MDIO 匯流排位置等。

驅動程式開發

DSA 交換機驅動程式需要實現一個 dsa_switch_ops 結構，其中包含以下描述的各種成員。

探測、註冊和裝置生命週期

DSA 交換機是總線上的常規 device 結構（平臺匯流排、SPI 匯流排、I2C 匯流排、MDIO 匯流排或其他匯流排）。DSA 框架不參與裝置核心的探測。

從驅動程式的角度來看，交換機註冊意味著將有效的 struct dsa_switch 指標傳遞給 dsa_register_switch()，通常從交換機驅動程式的探測函式中進行。提供的結構中必須包含以下有效成員：

  • ds->dev：將用於解析交換機的 OF 節點或平臺數據。

  • ds->num_ports：將用於建立此交換機的埠列表，並驗證 OF 節點中提供的埠索引。

  • ds->ops：指向 dsa_switch_ops 結構的指標，其中包含 DSA 方法的實現。

  • ds->priv：指向驅動程式私有資料結構的反向指標，可以在所有後續的 DSA 方法回撥中檢索。

此外，可以選擇配置 dsa_switch 結構中的以下標誌，以從 DSA 核心獲得特定於驅動程式的行為。設定時的行為記錄在 include/net/dsa.h 中的註釋中。

  • ds->vlan_filtering_is_global

  • ds->needs_standalone_vlan_filtering

  • ds->configure_vlan_while_not_filtering

  • ds->untag_bridge_pvid

  • ds->assisted_learning_on_cpu_port

  • ds->mtu_enforcement_ingress

  • ds->fdb_isolation

在內部，DSA 保留一個交換機樹陣列（交換機組），該陣列對核心是全域性的，並在註冊時將一個 dsa_switch 結構附加到一個樹。交換機附加到的樹 ID 由交換機 OF 節點的 dsa,member 屬性的第一個 u32 數字確定（如果缺失則為 0）。樹中的交換機 ID 由同一 OF 屬性的第二個 u32 數字確定（如果缺失則為 0）。註冊具有相同交換機 ID 和樹 ID 的多個交換機是非法的，會導致錯誤。使用平臺數據時，允許單個交換機和單個交換機樹。

在具有多個交換機的樹中，探測以不對稱方式進行。前 N-1 個 dsa_register_switch() 呼叫者僅將其埠新增到樹的埠列表 (dst->ports)，每個埠都有一個指向其關聯交換機的反向指標 (dp->ds)。然後，這些交換機提前退出其 dsa_register_switch() 呼叫，因為 dsa_tree_setup_routing_table() 確定該樹尚未完成（DSA 連結引用的所有埠尚未出現在該樹的埠列表中）。當最後一個交換機呼叫 dsa_register_switch() 時，該樹才變得完整，這將觸發所有交換機的有效初始化繼續（包括呼叫 ds->ops->setup()），所有這些都作為最後一個交換機探測函式的呼叫上下文的一部分。

註冊的反面發生在呼叫 dsa_unregister_switch() 時，該呼叫從樹的埠列表中刪除交換機的埠。當第一個交換機登出時，整個樹將被拆除。

DSA 交換機驅動程式必須實現其各自匯流排的 shutdown() 回撥，並從中呼叫 dsa_switch_shutdown() （dsa_unregister_switch() 執行的完整拆除的最小版本）。原因是 DSA 保留了對 conduit 網路裝置的引用，如果 conduit 裝置的驅動程式決定在關閉時解除繫結，則 DSA 的引用將阻止該操作完成。

必須呼叫 dsa_switch_shutdown() 或 dsa_unregister_switch()，但不能同時呼叫，並且即使已經呼叫了 shutdown()，裝置驅動程式模型也允許呼叫匯流排的 remove() 方法。因此，驅動程式需要實現 remove() 和 shutdown() 之間的互斥方法，方法是在任何一個執行後將其 drvdata 設定為 NULL，並在繼續執行任何操作之前檢查 drvdata 是否為 NULL。

在呼叫 dsa_switch_shutdown() 或 dsa_unregister_switch() 後，不得透過提供的 dsa_switch_ops 進行進一步的回撥，並且驅動程式可以釋放與 dsa_switch 關聯的資料結構。

交換機配置

  • get_tag_protocol：用於指示支援哪種型別的標記協議，應該是 dsa_tag_protocol 列舉中的有效值。返回的資訊不必是靜態的；驅動程式會傳遞 CPU 埠號，以及可能堆疊的上游交換機的標記協議，以防在支援的標記格式方面存在硬體限制。

  • change_tag_protocol：當預設標記協議與導線存在相容性問題或其他問題時，驅動程式可以支援在執行時透過裝置樹屬性或透過 sysfs 更改它。在這種情況下，對 get_tag_protocol 的進一步呼叫應報告當前使用的協議。

  • setup：交換機的設定函式，此函式負責設定具有其所需的所有內容的 dsa_switch_ops 私有結構：暫存器對映、中斷、互斥鎖、鎖等。此函式還應正確配置交換機以將所有網路介面彼此隔離，即，它們應由交換機硬體本身隔離，通常透過為每個埠建立一個基於埠的 VLAN ID，並且僅允許 CPU 埠和特定埠位於轉發向量中。平臺未使用的埠應停用。透過此函式後，交換機應被完全配置並準備好服務於任何型別的請求。建議在此設定函式期間發出交換機的軟體重置，以避免依賴先前軟體代理（如引導載入程式/韌體）先前可能已配置的內容。負責撤消在此處完成的任何適用分配或操作的方法是 teardown。

  • port_setup 和 port_teardown：用於初始化和銷燬每個埠的資料結構的方法。必須從這些方法中完成某些操作，例如註冊和登出 devlink 埠區域，否則它們是可選的。僅當先前已設定埠時，才會拆除埠。可以在探測期間設定埠，然後在之後立即將其拆除，例如，如果找不到其 PHY。在這種情況下，DSA 交換機的探測將繼續進行，而沒有該特定埠。

  • port_change_conduit：一種方法，可以透過該方法更改使用者埠和 CPU 埠之間的關聯性（用於流量終止目的的關聯）。預設情況下，樹中的所有使用者埠都分配給對它們有意義的第一個可用 CPU 埠（在大多數情況下，這意味著樹的使用者埠都分配給同一個 CPU 埠，除了 commit 2c0b03258b8b 中描述的 H 拓撲）。port 引數表示使用者埠的索引，conduit 引數表示新的 DSA 導線 net_device。與新導線關聯的 CPU 埠可以透過檢視 struct dsa_port *cpu_dp = conduit->dsa_ptr 來檢索。此外，導線也可以是 LAG 裝置，其中所有從屬裝置都是物理 DSA 導線。LAG DSA 也具有有效的 conduit->dsa_ptr 指標，但是，這不是唯一的，而是第一個物理 DSA 導線（LAG 從屬裝置）的 dsa_ptr 的副本。在 LAG DSA 導線的情況下，將為與物理 DSA 導線關聯的物理 CPU 埠單獨發出對 port_lag_join 的進一步呼叫，請求它們建立與 LAG 介面關聯的硬體 LAG。

Ethtool 操作

  • get_strings：ethtool 函式，用於查詢驅動程式的字串，通常返回統計資訊字串、私有標誌字串等。

  • get_ethtool_stats：ethtool 函式，用於查詢每個埠的統計資訊並返回其值。DSA 使用使用者網路裝置的常規統計資訊覆蓋：來自網路裝置的 RX/TX 計數器，以及每個埠的交換機驅動程式特定統計資訊。

  • get_sset_count：ethtool 函式，用於查詢統計資訊項的數量。

  • get_wol：ethtool 函式，用於獲取每個埠的 Wake-on-LAN 設定，對於某些實現，如果此介面需要參與 Wake-on-LAN，則此函式還可以查詢導線網路裝置的 Wake-on-LAN 設定。

  • set_wol：ethtool 函式，用於配置每個埠的 Wake-on-LAN 設定，與 set_wol 直接對應，具有類似的限制。

  • set_eee：ethtool 函式，用於配置交換機埠 EEE（綠色乙太網）設定，可以選擇呼叫 PHY 庫以在 PHY 級別啟用 EEE（如果相關）。此函式應在交換機埠 MAC 控制器和資料處理邏輯中啟用 EEE。

  • get_eee：ethtool 函式，用於查詢交換機埠 EEE 設定，此函式應返回交換機埠 MAC 控制器和資料處理邏輯的 EEE 狀態，並查詢 PHY 以獲取其當前配置的 EEE 設定。

  • get_eeprom_len：ethtool 函式，返回給定交換機的 EEPROM 長度/大小（以位元組為單位）。

  • get_eeprom：ethtool 函式，返回給定交換機的 EEPROM 內容。

  • set_eeprom：ethtool 函式，將指定的資料寫入給定的交換機 EEPROM。

  • get_regs_len：ethtool 函式，返回給定交換機的暫存器長度。

  • get_regs：ethtool 函式，返回乙太網交換機內部暫存器內容。此函式可能需要在 ethtool 中使用使用者端程式碼來很好地列印暫存器值和暫存器。

電源管理

  • suspend：當系統進入掛起狀態時由 DSA 平臺裝置呼叫的函式，應使所有乙太網交換機活動停止，但保持參與 Wake-on-LAN 的埠處於活動狀態，以及其他受支援的喚醒邏輯。

  • resume：當系統恢復時由 DSA 平臺裝置呼叫的函式，應恢復所有乙太網交換機活動，並將交換機重新配置為完全活動狀態。

  • port_enable：當埠在管理上啟動時由 DSA 使用者網路裝置 ndo_open 函式呼叫的函式，此函式應完全啟用給定的交換機埠。如果埠是橋成員，DSA 會將埠標記為 BR_STATE_BLOCKING，如果不是，則標記為 BR_STATE_FORWARDING，並將這些更改向下傳播到硬體。

  • port_disable：當埠在管理上關閉時由 DSA 使用者網路裝置 ndo_close 函式呼叫的函式，此函式應完全停用給定的交換機埠。如果此埠在作為橋成員時被停用，DSA 會將埠標記為 BR_STATE_DISABLED，並將更改傳播到硬體。

地址資料庫

交換硬體應具有一個用於 FDB 條目的表，但是並非所有表都同時處於活動狀態。地址資料庫是在埠狀態下處於活動狀態的 FDB 條目的子集（分割槽）（可以透過 RX 上的地址學習或 TX 上的 FDB 查詢進行匹配）。地址資料庫有時在本文件中稱為“FID”（過濾 ID），儘管底層實現可以選擇硬體可用的任何內容。

例如，屬於 VLAN 感知度低的橋（當前VLAN 感知度低）的所有埠都應在由驅動程式與該橋關聯的資料庫中學習源地址（而不是與其他 VLAN 感知度低的橋關聯）。在轉發和 FDB 查詢期間，在 VLAN 感知度低的橋埠上接收的資料包應能夠找到具有與資料包相同的 MAC DA 的 VLAN 感知度低的 FDB 條目，該條目存在於同一橋的另一個埠成員上。同時，如果該條目指向作為不同 VLAN 感知度低的橋的成員的埠（因此與不同的地址資料庫關聯），則 FDB 查詢過程必須能夠找不到具有與資料包相同的 MAC DA 的 FDB 條目。

類似地，每個解除安裝的 VLAN 感知橋的每個 VLAN 都應具有一個關聯的地址資料庫，該資料庫由作為該 VLAN 成員的所有埠共享，但不由屬於同一 VID 的不同橋的埠共享。

在此上下文中，VLAN 感知度低的資料庫意味著所有資料包都應匹配它，而與 VLAN ID 無關（僅 MAC 地址查詢），而 VLAN 感知資料庫意味著資料包應基於已分類的 802.1Q 標頭（或未標記時的 pvid）中的 VLAN ID 進行匹配。

在橋層，VLAN 感知度低的 FDB 條目的特殊 VID 值為 0，而 VLAN 感知 FDB 條目的非零 VID 值。請注意，VLAN 感知度低的橋可能具有 VLAN 感知（非零 VID）FDB 條目，而 VLAN 感知橋可能具有 VLAN 感知度低的 FDB 條目。與硬體一樣，軟體橋也保持單獨的地址資料庫，並透過 switchdev 將屬於這些資料庫的 FDB 條目解除安裝到硬體，相對於資料庫變得活動或不活動的那一刻非同步。

當用戶埠在獨立模式下執行時，其驅動程式應將其配置為使用一個單獨的資料庫，稱為埠私有資料庫。這與上述資料庫不同，並且應儘可能減少對作為獨立埠（資料包進入，資料包輸出到 CPU 埠）的操作的阻礙。例如，在入口處，它不應嘗試學習入口流量的 MAC SA，因為學習是橋接層服務，並且這是一個獨立埠，因此它會消耗無用的空間。在沒有地址學習的情況下，埠私有資料庫在一種簡單的實現中應該是空的，在這種情況下，所有接收的資料包都應簡單地泛洪到 CPU 埠。

DSA（級聯）和 CPU 埠也稱為“共享”埠，因為它們服務於多個地址資料庫，並且資料包應關聯到的資料庫通常嵌入在 DSA 標記中。這意味著 CPU 埠可以同時傳輸來自獨立埠（由硬體在一個地址資料庫中分類）和來自橋埠（已分類到另一個地址資料庫）的資料包。

滿足某些條件的交換機驅動程式能夠透過從交換機的泛洪域中刪除 CPU 埠來最佳化簡單的配置，並且僅使用指向 CPU 埠的 FDB 條目對硬體進行程式設計，已知軟體對這些 MAC 地址感興趣。與已知 FDB 條目不匹配的資料包不會傳遞到 CPU，這將節省建立 skb 只是為了丟棄它所需的 CPU 週期。

DSA 能夠對以下型別的地址執行主機地址過濾：

  • 埠的主單播 MAC 地址 (dev->dev_addr)。這些地址與各個使用者埠的埠私有資料庫關聯，並且透過 port_fdb_add 通知驅動程式將其安裝到 CPU 埠。

  • 埠的輔助單播和多播 MAC 地址（透過 dev_uc_add() 和 dev_mc_add() 新增的地址）。這些地址也與各個使用者埠的埠私有資料庫關聯。

  • 本地/永久橋 FDB 條目 (BR_FDB_LOCAL)。這些是橋埠的 MAC 地址，必須在本地終止資料包，而不是轉發。它們與該橋的地址資料庫關聯。

  • 安裝到與某些 DSA 交換機埠位於同一橋中的外部（非 DSA）介面的靜態橋 FDB 條目。這些地址也與該橋的地址資料庫關聯。

  • 在與某些 DSA 交換機埠位於同一橋中的外部介面上動態學習的 FDB 條目，前提是驅動程式將 ds->assisted_learning_on_cpu_port 設定為 true。這些地址與該橋的地址資料庫關聯。

對於下面詳述的各種操作，DSA 提供了一個 dsa_db 結構，可以是以下型別：

  • DSA_DB_PORT：要安裝或刪除的 FDB（或 MDB）條目屬於使用者埠 db->dp 的埠私有資料庫。

  • DSA_DB_BRIDGE：條目屬於橋 db->bridge 的地址資料庫之一。驅動程式應完成此橋的 VLAN 感知度低的資料庫和每個 VID 資料庫之間的分離。

  • DSA_DB_LAG：條目屬於 LAG db->lag 的地址資料庫。注意：DSA_DB_LAG 當前未使用，將來可能會刪除。

作用於 port_fdb_add、port_mdb_add 等中的 dsa_db 引數的驅動程式應將 ds->fdb_isolation 宣告為 true。

DSA 將每個解除安裝的橋和每個解除安裝的 LAG 與一個從一開始的 ID 關聯（struct dsa_bridge :: num、struct dsa_lag :: id），以便在共享埠上對地址進行引用計數。驅動程式可以在 DSA 的編號方案（可以透過 db->bridge.num 和 db->lag.id 讀取 ID）上搭載，也可以實現自己的編號方案。

只有宣告支援 FDB 隔離的驅動程式才會收到屬於 DSA_DB_PORT 資料庫的 CPU 埠上的 FDB 條目的通知。出於相容性/遺留原因，即使驅動程式不支援 FDB 隔離，也會將 DSA_DB_BRIDGE 地址通知給驅動程式。但是，在這種情況下，db->bridge.num 和 db->lag.id 始終設定為 0（表示缺少隔離，用於引用計數目的）。

請注意，交換機驅動程式不一定需要為每個獨立的User Port實現物理上分離的地址資料庫。由於埠私有資料庫中的FDB條目始終指向CPU埠，因此不存在錯誤轉發決策的風險。在這種情況下，所有獨立的埠可以共享同一個資料庫，但是主機過濾地址的引用計數（如果埠的MAC地址仍在被其他埠使用，則不刪除該埠的FDB條目）將成為驅動程式的責任，因為DSA並不知道埠資料庫實際上是共享的。這可以透過呼叫dsa_fdb_present_in_other_db() 和 dsa_mdb_present_in_other_db()來實現。缺點是每個User Port的RX過濾列表實際上是共享的，這意味著User Port A可能會接收到本不應該接收的MAC DA資料包，僅僅是因為該MAC地址在User Port B的RX過濾列表中。但是，這些資料包仍然會在軟體中被丟棄。

橋接層

解除安裝橋接轉發平面是可選的，由以下方法處理。它們可能不存在，返回-EOPNOTSUPP，或者ds->max_num_bridges可能非零且超出限制，在這種情況下，仍然可以加入橋接埠，但資料包轉發將在軟體中進行，並且軟體橋接下的埠必須保持與獨立操作相同的方式配置，即停用所有橋接服務功能（地址學習等），並且僅將所有接收到的資料包傳送到CPU埠。

具體來說，當埠成功返回port_bridge_join方法時，該埠開始解除安裝橋接的轉發平面，並在呼叫port_bridge_leave後停止解除安裝。解除安裝橋接意味著根據軟體橋接埠的狀態自主學習FDB條目，以及自主轉發（或廣播）接收到的資料包，而無需CPU干預。即使解除安裝橋接埠，這也是可選的。期望Tagging協議驅動程式為已經在入口交換機埠的轉發域中自主轉發的資料包呼叫dsa_default_offload_fwd_mark(skb)。DSA透過dsa_port_devlink_setup()，將屬於同一樹ID的所有交換機埠視為同一橋接轉發域的一部分（能夠相互自主轉發）。

解除安裝橋接的TX轉發過程與簡單地解除安裝其轉發平面是一個不同的概念，指的是某些驅動程式和Tagging協議組合能夠將來自橋接裝置傳輸功能的單個skb傳輸到潛在的多個出口埠（從而避免在軟體中克隆它）。

橋接請求此行為的資料包稱為資料平面資料包，並且在Tagging協議驅動程式的xmit函式中將skb->offload_fwd_mark設定為true。資料平面資料包受FDB查詢、CPU埠上的硬體學習的影響，並且不覆蓋埠的STP狀態。此外，資料平面資料包的複製（多播、廣播）在硬體中處理，並且橋接驅動程式將為每個可能需要或不需要複製的資料包傳輸單個skb。

啟用TX轉發解除安裝後，Tagging協議驅動程式負責將資料包注入到硬體的資料平面中，並使其指向埠所屬的正確的橋接域 (FID)。該埠可能無法識別VLAN，在這種情況下，FID必須等於驅動程式用於與該橋接關聯的、不能識別VLAN的地址資料庫的FID。或者，橋接可以識別VLAN，在這種情況下，保證資料包也使用橋接處理此資料包的VLAN ID進行VLAN標記。硬體有責任在出口未標記埠上取消標記VID，或在出口已標記埠上保留標記。

  • port_bridge_join：當給定的交換機埠新增到橋接時呼叫的橋接層函式，此函式應該在交換機級別執行必要的操作，以允許加入的埠新增到相關的邏輯域，以便它與其他橋接成員進行流量的入口/出口。透過將tx_fwd_offload引數設定為true，還可以解除安裝此橋接的TX轉發過程。

  • port_bridge_leave：當給定的交換機埠從橋接中移除時呼叫的橋接層函式，此函式應該在交換機級別執行必要的操作，以拒絕離開的埠從剩餘橋接成員進行流量的入口/出口。

  • port_stp_state_set：當橋接層計算出給定的交換機埠STP狀態並應將其傳播到交換機硬體以轉發/阻止/學習流量時呼叫的橋接層函式。

  • port_bridge_flags：當埠必須配置其設定（例如未知流量的廣播或源地址學習）時呼叫的橋接層函式。交換機驅動程式負責使用停用的地址學習功能和所有型別流量的出口廣播來初始設定獨立的埠，然後當埠加入和離開橋接時，DSA核心會通知橋接埠標誌的任何更改。DSA當前不管理CPU埠的橋接埠標誌。假設地址學習應該在CPU埠上靜態啟用（如果硬體支援），並且由於DSA核心中缺少顯式的地址過濾機制，還應該啟用向CPU埠的廣播。

  • port_fast_age：當必須重新整理埠上動態學習的FDB條目時呼叫的橋接層函式。當從應該進行學習的STP狀態過渡到不應該學習的STP狀態，或者當離開橋接，或者當透過port_bridge_flags關閉地址學習時，會呼叫此函式。

橋接 VLAN 過濾

  • port_vlan_filtering：當為橋接配置開啟或關閉VLAN過濾時呼叫的橋接層函式。如果硬體級別不需要執行任何特定操作，則無需實現此回撥。開啟VLAN過濾後，必須對硬體進行程式設計，以拒絕VLAN ID位於已程式設計的允許VLAN ID對映/規則之外的802.1Q幀。如果交換機埠中沒有程式設計PVID，則還必須拒絕未標記的幀。關閉後，交換機必須接受任何802.1Q幀，而不管它們的VLAN ID如何，並且允許未標記的幀。

  • port_vlan_add：當為給定的交換機埠配置VLAN（已標記或未標記）時呼叫的橋接層函式。只有當外部橋接埠也是VLAN的成員（並且需要在軟體中進行轉發），或者VLAN已安裝到橋接裝置本身的VLAN組中以用於終止目的時，CPU端口才會成為VLAN的成員（bridge vlan add dev br0 vid 100 self）。共享埠上的VLAN是引用計數的，當沒有使用者剩餘時會被刪除。驅動程式不需要手動在CPU埠上安裝VLAN。

  • port_vlan_del：當從給定的交換機埠中刪除VLAN時呼叫的橋接層函式

  • port_fdb_add：當橋接想要安裝轉發資料庫條目時呼叫的橋接層函式，應在與此VLAN ID關聯的轉發資料庫中，使用指定的VLAN Id對交換機硬體進行程式設計，以儲存指定的地址。

  • port_fdb_del：當橋接想要刪除轉發資料庫條目時呼叫的橋接層函式，應該對交換機硬體進行程式設計，以從指定的VLAN ID中刪除指定的MAC地址（如果它已對映到此埠轉發資料庫中）

  • port_fdb_dump：由物理DSA埠介面上的 ndo_fdb_dump 呼叫的橋接繞過函式。由於 DSA 不嘗試使其硬體 FDB 條目與軟體橋接保持同步，因此該方法旨在檢視使用者埠在硬體資料庫中可見的條目。此函式報告的條目在 bridge fdb show 命令的輸出中具有 self 標誌。

  • port_mdb_add：當橋接想要安裝多播資料庫條目時呼叫的橋接層函式。應該在與此VLAN ID關聯的轉發資料庫中，使用指定的VLAN ID對交換機硬體進行程式設計，以儲存指定的地址。

  • port_mdb_del：當橋接想要刪除多播資料庫條目時呼叫的橋接層函式，應該對交換機硬體進行程式設計，以從指定的VLAN ID中刪除指定的MAC地址（如果它已對映到此埠轉發資料庫中）。

IEC 62439-2 (MRP)

媒體冗餘協議是一種拓撲管理協議，針對環形網路的快速故障恢復時間進行了最佳化，它的一些元件實現為橋接驅動程式的功能。MRP 使用管理 PDU（測試、拓撲、鏈路關閉/開啟、選項），以 01:15:4e:00:00:0x 的多播目標 MAC 地址範圍和 0x88e3 的 EtherType 傳送。根據節點在環中的角色（MRM：媒體冗餘管理器，MRC：媒體冗餘客戶端，MRA：媒體冗餘自動管理器），某些 MRP PDU 可能需要在本地終止，而另一些可能需要轉發。MRM 還可能受益於將某些 MRP PDU（測試）的建立和傳輸解除安裝到硬體。

通常，MRP 例項可以在任何網路介面之上建立，但是在具有解除安裝資料路徑（例如 DSA）的裝置的情況下，即使硬體不瞭解 MRP，它也必須能夠在驅動程式繼續進行軟體實現之前從結構中提取 MRP PDU。DSA 今天沒有任何瞭解 MRP 的驅動程式，因此它僅監聽軟體輔助正常工作所需的最低限度的 switchdev 物件。以下詳細介紹了這些操作。

  • port_mrp_add 和 port_mrp_del：當建立/刪除具有特定環 ID、優先順序、主埠和輔助埠的 MRP 例項時通知驅動程式。

  • port_mrp_add_ring_role 和 port_mrp_del_ring_role：當 MRP 例項在 MRM 或 MRC 之間更改環角色時呼叫的函式。這會影響哪些 MRP PDU 應捕獲到軟體，哪些應自主轉發。

IEC 62439-3 (HSR/PRP)

並行冗餘協議 (PRP) 是一種網路冗餘協議，其工作原理是透過兩個獨立的 L2 網路（不知道資料包中攜帶的 PRP 尾部標籤）複製和序列編號資料包，並在接收器處消除重複項。高可用性無縫冗餘 (HSR) 協議在概念上類似，只是所有攜帶冗餘流量的節點都知道它已進行 HSR 標記（因為 HSR 使用 EtherType 為 0x892f 的標頭）並且以環形拓撲物理連線。HSR 和 PRP 都使用監管幀來監控網路的執行狀況和發現其他節點。

在 Linux 中，HSR 和 PRP 都在 hsr 驅動程式中實現，該驅動程式例項化一個具有兩個成員埠的虛擬的、可堆疊的網路介面。驅動程式僅實現 DANH（實現 HSR 的雙鏈接節點）和 DANP（實現 PRP 的雙鏈接節點）的基本角色；不實現 RedBox 和 QuadBox 的角色（因此，將 hsr 網路介面與物理交換機埠橋接不會產生預期的結果）。

如果驅動程式能夠解除安裝 DANP 或 DANH 的某些功能，則應按照 Documentation/networking/netdev-features.rst 的文件指示宣告相應的 netdev 功能。此外，必須實現以下方法

  • port_hsr_join：當給定的交換機埠新增到 DANP/DANH 時呼叫的函式。驅動程式可能返回 -EOPNOTSUPP，在這種情況下，DSA 將回退到軟體實現，其中來自此埠的所有流量都將傳送到 CPU。

  • port_hsr_leave：當給定的交換機埠離開 DANP/DANH 並返回作為獨立埠的正常執行時呼叫的函式。

TODO

使 SWITCHDEV 和 DSA 收斂到統一的程式碼庫

SWITCHDEV 正確地處理了抽象具有解除安裝功能的硬體的網路堆疊，但不強制執行嚴格的交換機裝置驅動程式模型。另一方面，DSA 強制執行相當嚴格的裝置驅動程式模型，並處理大多數交換機特定的問題。在某些時候，我們應該設想這兩個子系統之間的合併，並獲得兩全其美的好處。