# AI Networking - RoCEv2 and the role of netdev Navigation: [[../index|index]] | [[../overview|overview]] ## 概要 David Ahern と Leon Romanovsky が Netdev 0x19(2025年3月、Zagreb)のワークショップで示したスライド資料である。 AI訓練では、LLMの大規模化に伴ってノード間で移動するデータ量が増え、各ラウンドの完了時間はテールレイテンシに強く左右される。 資料は、少数の大規模フローを処理するAI訓練ネットワークにおいて、通常のsocket networking、RDMA verbs、RoCEv2、Linux TCPの新しいゼロコピー機構を同じホスト内ネットワークの観点から比較する。 ## 主要メッセージ - Netdevコミュニティ内で、LinuxベースのAPIと各種ネットワークトランスポートに関する議論の基盤をそろえることがワークショップの目的である。 - AI訓練ネットワークは、数百Gbpsで動く少数の大規模フロー、GPUメモリへの直接読み書き、順序どおりのペイロード配置、ハードウェアオフロード、パケット損失回避を要求する。 - Linuxの`net_device`はポートのup/down、carrier、速度、MTUを保持し、ネットワークアドレス、近隣エントリ、FIBエントリへの参照を提供する。 - RDMAのデータ経路はユーザー空間が管理するハードウェアキューとNICのオフロードで構成され、システムコール、カーネル側ページプール、パケットごとの`skb`生成を避ける。 - RoCEv2はEthernet + IP/IPv6 + UDP + BTH + 操作固有のトランスポートヘッダで構成され、RDMAの性能経路とLinuxネットワークの制御・構成モデルを接続する。 - 同一条件の測定では、socket networkingの単一フローは215-220Gbps、RoCEv2の`ib_send_bw`は392Gbpsであり、400Gbpsを単一フローで使い切る難しさとRDMAの優位性を示す。 - `devmem`はGPUメモリへゼロコピーで受信できるが、ページプール、システムコール、匿名メモリプール型のバッファ、ペイロードの線形化が残るため、資料では低100Gbps帯に適した機構と位置づける。 - Linux TCPとQPを組み合わせる案は、通常のsocket APIを制御経路として残し、TCPの輻輳制御・ACK・SACK・タイムスタンプ・再送と、QPのフロー固有ハードウェアキューをデータ経路へ組み合わせる。 ## 視覚的に重要な図表 **p.4 AI訓練ノードとネットワーク構成** ![[_attachments/netdev-0x19-ai-networking-roce-netdev/page-004.png]] CPUとホストメモリ、PCIe switch、8個のGPU/NIC、GPU fabricを一つの訓練ノードとして描き、各ノードがLeaf-Spineネットワークへ接続する構成を示す。 **p.7 netdevとLinuxネットワークスタック** ![[_attachments/netdev-0x19-ai-networking-roce-netdev/page-007.png]] ユーザー空間のsocket APIからTCP/UDP、IP/IPv6、アドレス・FIB・neighbor cacheを経て`netdev driver`とハードウェアキューへ至る経路を示す。 **p.8 IB verbsソフトウェア垂直スタック** ![[_attachments/netdev-0x19-ai-networking-roce-netdev/page-008.png]] `libibverbs`、`librdmacm`、vendor provider、verbs API、IB driver、ハードウェアキューの制御経路とデータ経路を分けて示す。 **p.10 IBスタックとnetdevの接続** ![[_attachments/netdev-0x19-ai-networking-roce-netdev/page-010.png]] GID cache、address vectors、FIB・neighbor lookup、ポート状態、netdev通知、IPsec/MACsecの関係を、IB driverとnetdev driverの共有ハードウェア経路として整理する。 **p.11 RoCEv2のプロトコル構造** ![[_attachments/netdev-0x19-ai-networking-roce-netdev/page-011.png]] RoCEv2のUDP/IP/Ethernetカプセル化、BTHと操作別拡張ヘッダ、送信・応答・完了のモデル、メッセージ内のFIRST/MIDDLE/LAST、順序どおりの到着要求を列挙する。 **p.13-14 socket networkingとRoCEv2の性能** ![[_attachments/netdev-0x19-ai-networking-roce-netdev/page-013.png]] ![[_attachments/netdev-0x19-ai-networking-roce-netdev/page-014.png]] ConnectX-7の400Gポートを使い、socket networkingでは単一フロー215-220Gbps・2フロー397Gbps、RoCEv2では単一フロー392Gbpsという比較を示す。 **p.15 RDMAとRoCEv2がオーバーヘッドを避ける機構** ![[_attachments/netdev-0x19-ai-networking-roce-netdev/page-015.png]] 制御経路とデータ経路の分離、ハードウェアによる完全オフロード、ユーザー管理メモリ領域、ゼロコピー・順序どおりのペイロード配置、`skb`非生成をまとめる。 **p.16 Linux TCPとdevmem** ![[_attachments/netdev-0x19-ai-networking-roce-netdev/page-016.png]] `dmabuf`経由のGPUメモリを専用のflow Rx queueとページプールへ接続する構成を示し、通常のnetdev RSS queueとGPU向け経路を区別する。 **p.17 Linux TCPとio_uring** ![[_attachments/netdev-0x19-ai-networking-roce-netdev/page-017.png]] socket APIを制御経路、`io_uring`のユーザー・カーネルキューをデータ経路とする構成を示し、通常のネットワークシステムコール削減とページプール供給の関係を表す。 **p.18 Linux TCPとQP** ![[_attachments/netdev-0x19-ai-networking-roce-netdev/page-018.png]] 通常のsocket APIとTCPを制御経路に残し、`libibverbs`、provider、verbs API、IB driver、netdev driver、QPのキューをデータ経路として組み合わせる提案を示す。 **p.19-20 TCP上のメッセージフレーミング** ![[_attachments/netdev-0x19-ai-networking-roce-netdev/page-019.png]] ![[_attachments/netdev-0x19-ai-networking-roce-netdev/page-020.png]] TCP optionの40B制約と12Bのtimestamp optionを前提に、メッセージ番号、opcode、メッセージ内オフセット、4B immediate data、ICRCを扱う`tcp_bth`構造を提案する。 ## 内容の整理 ### AI訓練ネットワークのホスト要件 資料はMetaの24,000 GPU・3,000ノード・400Gbpsポートと、xAIの単一RDMAファブリック上の100,000 GPU・400Gbpsポートを例に挙げ、今後さらに大きなクラスタへ拡張する状況を示す。 モデルは数千億から数兆パラメータへ拡大し、ノードとGPU間で移動するデータも増えるため、各訓練ラウンドの時間はテールレイテンシに支配される。 この前提では、1ホストあたり数百万フローをさばく一般的なネットワークではなく、GPUごとの400Gbpsポートを少数の大規模フローが使う。 そのため、データ経路からOSを外し、メモリコピーをなくし、NICがGPUメモリを直接読み書きし、ハードウェアがパケットを適切なメッセージ・バッファ順序へ配置する必要がある。 Ethernetヘッダ生成のような反復的処理はハードウェアへ移し、輻輳時には送信側を減速させて受信側の過負荷と再送を避ける。 ### netdevとIB verbsの責任分担 `net_device`はポート状態とネットワーク構成情報を保持する。 受信パケット用のページプール、TCP/UDPとIP/IPv6、システムコール、ゼロコピーAPI、packet tap・netfilter・tc・eBPFなどのフックは、socket networking側の機能として示される。 一方、IB verbsは、ユーザー空間が管理するCompletion Queue、Receive Queue、Send Queueへwork requestを投入し、完了をCompletion Queueから受け取る。 `SEND`は受信側がバッファを事前登録し、`RDMA_WRITE`は宛先アドレスと長さを指定して受信バッファを要求せず、`RDMA_READ`は要求側が必要な応答バッファを指定してデータを取りに行く。 kernel moduleと`rdma-core`のproviderは別々の部品ではなく、一体の実装として扱う必要がある。 RoCEv2では、接続管理や帯域外のメタデータ交換にsocketまたは第二のQPを使える。 GID cacheはnetdev上のアドレスを参照し、address vectorはFIBとneighbor lookupを利用し、IBポート状態はnetdevのup/down状態を追跡する。 RoCE MTUはnetdev MTUに基づき、IPsecやMACsecなどのデータフローオフロードもnetdevの操作へ接続される。 ### 性能比較の条件と結果 比較はConnectX-7の400Gポートで行い、socket側には9000 MTU、約512kBのBig TCP、GRO/TSO、8kB ring、32MBのsocket buffer、hugepages、pinned flow、netfilter・qdisc・packet socket・IOMMUを使わない条件、socketのRx/Txゼロコピー相当を設定している。 これはソフトウェアを最大限に押し上げるための条件であり、資料自身が一部は現実的でないと注記している。 socket networkingでは単一フローが215-220Gbps、2フローが397Gbpsに達する一方、受信側softirqは100%に達し、送信側は60%に達する。 プロファイルでは`mlx5e_copy_skb_header`が30.90%で最大の項目となり、`mlx5e_skb_from_cqe_mpwrq_nonlinear`、`mlx5e_add_skb_shared_info_frag`、ページ返却・DMA同期・GRO/TCP受信処理などが続く。 資料は、単一フローで400Gを使い切ることはフルスタックsocket networkingでは大きな課題だと結論づける。 同じハードウェアで`ib_send_bw`の`IBV_WR_SEND`を使うRoCEv2は、2MBメッセージ、4096 RoCE MTU、受信側にバッファを事前登録する条件で、単一フロー392Gbpsに達する。 この測定は`RDMA_WRITE`ではなく`SEND`を使い、netdevモデルにできるだけ近い比較として位置づけられている。 ### Linux TCPの拡張と残る制約 Linux TCPのdevmemはv6.12で受信側のGPUメモリ利用を可能にする。 `dmabuf`経由のGPUメモリをページプールへ接続し、専用の受信キューへフローを誘導するが、充填済みバッファの通知とページプールへの返却にシステムコールを要する。 また、データは順序どおりに直接配置されるのではなく、匿名メモリプール型のバッファへ入り、GPUスレッドが消費する前に線形化のためのコピーが必要になる。 送信側のGPUメモリゼロコピーは資料時点で作業中であり、devmemは低100Gbps帯に適すると整理される。 `io_uring`は制御経路に通常のsocket APIを残し、データ経路のread/writeをユーザー・カーネルキューで管理する。 v6.15でCPUメモリの受信ゼロコピーが統合され、v6.1で送信ゼロコピーが統合されたと説明されるが、どちらもGPUメモリは扱わない。 資料が引用するパッチセットでは単一フロー性能は116Gとされる。 Linux TCPとQPを接続する案では、socket APIでBig TCPとGRO/TSOなどを設定し、TCPフローごとのQPとハードウェアキューを使う。 データ経路のsocket管理をIB driverへ引き渡すことで、TCPの輻輳制御、ACK、SACK、タイムスタンプ、再送を残しながら、上下の不要な処理を迂回する。 ただしTCPはバイトストリームなのでメッセージフレーミングが必要であり、TCP optionの40B制約の中で、メッセージ番号・opcode・オフセット・ICRC・immediate data・timestampを収める設計課題がある。 ## 口頭説明・補足 音声・動画およびtranscriptは取得していない。 したがって、本ページの内容はスライド画像とPDF抽出テキスト、公式セッションページに記載された概要だけに基づく。 ## Q&A スライドには質疑応答の記録がない。 Agendaでは参加者から質問を受けながら進める対話形式を想定しているが、実際の議論内容は確認できない。 ## 概念・実体への接続 - 概念: [[RDMA]] / [[RoCE設計課題]] / [[ホストネットワークスタック性能]] / [[TCP/IPスタック統合|TCP/IPスタック統合]] / [[カーネルバイパスネットワーキング]] / [[Linuxカーネルインタフェース]] - 実体: [[David Ahern]] / [[Leon Romanovsky]] / [[Mellanox]] - 関連資料: [[@2023__SpeakerDeck__クラウドデータセンターネットワークのいまとこれから]] ## 限界・不確実点 - タイトルスライドは「March 2025」と記載する。日単位の発表日はスライドと公式ページから確認できないため、`date_published`は月単位とした。 - Meta・xAIのGPU規模はスライドに記載された紹介値であり、この資料内で独立検証された測定値ではない。 - socket networkingとRoCEv2の性能値はConnectX-7の比較環境に依存する。socket側には最大性能を引き出すための非現実的な設定も含まれるため、一般的な環境の性能差へ直接一般化できない。 - `devmem`の「低100Gbps帯に適する」、`io_uring`の単一フロー116G、TCPとQPを接続する案はスライドの説明・提案であり、資料内に追試可能な詳細ベンチマークはない。 - v6.12、v6.15、v6.1の機能説明はスライド記載に基づく。資料は対応コミットやカーネル文書へのリンクを示していない。 ## 出典 - [公式セッションページ](https://netdevconf.info/0x19/sessions/workshop/ai-networks-rocev2-and-the-role-of-netdev.html) — タイトル、登壇者(Chairs)、Netdev 0x19の開催地、ワークショップ概要 - [スライドPDF](https://netdevconf.org/0x19/docs/netdev-0x19-paper18-talk-slides/netdev-0x19-AI-networking-RoCE-and-netdev.pdf) — 24ページのスライド画像と抽出テキスト