← 一覧へ戻る

Claude が書いた記事

eSwitch と vSwitch ── NIC の中のスイッチと、ホスト OS の中のスイッチ

仮想基盤なしのベアメタルに SmartNIC を挿す。このとき、NIC の中のスイッチ (eSwitch) は必要か？何をする？ ── という疑問から始まった学習ログ。

俺の最初の疑問

前提を先に固定する。仮想基盤なし。Hyper-V も KVM も無い、物理サーバーに Ubuntu Server を直インストールしたベアメタル。そこに SmartNIC が挿さっている。

俺の理解では、SmartNIC は OS の処理をオフロードして高速化するもので、その SmartNIC の内部にスイッチ (仮想スイッチ) がある。仮想基盤を使っているときは、各 VM のインターフェイス (VF みたいなやつ) がそのスイッチに繋がる。じゃあ仮想基盤を使わんとき、そのスイッチは何するんや？

そしてもう一個。この「NIC の中のスイッチ」＝ eSwitch と、仮想基盤で聞く vSwitch は同じものなんか？ 俺の感覚では、eSwitch は NIC の中に在る。vSwitch は NIC の中には無くて、ホスト OS の中 (ストレージ) に在るはずや。ここをはっきりさせたい。

まず一言でいうと

先に結論。その感覚は合っている。ただ「在る場所」に一段足すと、モヤが完全に晴れる。

eSwitch と vSwitch は、役割は同じで、居場所と材質がちがう。

  • vSwitch ── ソフト (プログラム)。コードはホスト OS のストレージに置かれ、動くときはホストの CPU で実行される。NIC の中には居ない。
  • eSwitch ── ハード (回路)。NIC のシリコン (チップ) に焼かれている。どこかに保存されたコードやなく、物理的に NIC の中に在る。

役割はどっちも同じで、NIC に内側から繋がった相手 (同じマシンの中の VM・コンテナ・ホスト OS) と、ケーブルの先の相手 ── この間で、届いたパケットを宛先へ振り分けて渡すこと。ちがうのは、それを CPU 上のソフトでやるか (vSwitch)、NIC のシリコンでやるか (eSwitch) だけ。eSwitch は vSwitch の仕事をハードで代行する装置、という間柄や。

スイッチ (eSwitch も vSwitch も役割は同じ) は、同じマシンの内部で繋がった相手 (VM・コンテナ・ホスト OS) と、ケーブルの先の相手との間で、届いたパケットを宛先へ振り分ける。内側どうし (VM ↔ コンテナ) の通信は、外に出さずスイッチの中で折り返す (east-west)。

何と比べるとわかるか

いちばん効くのは「頭と筋肉」の対比。

vSwitcheSwitch
正体ソフト (プログラム)ハード (回路)
居場所ホスト OS の中 (カーネル)NIC のシリコンの中
例Open vSwitch・Linux bridge・Hyper-V vSwitchNVIDIA / Mellanox の eSwitch
パケットを捌くとホスト CPU を食うCPU を食わない
役割届いたパケットを宛先へ振り分けて転送同じ

近代の SmartNIC では、この 2 つは敵ではなく 分業している。

  • vSwitch (頭) ── どの相手へ送るか、どのフローを通す / 落とすか、を 決める (control plane)。
  • eSwitch (筋肉) ── 決まったルールに従って、1 パケットずつ 実際に転送する (data plane)。

動き方はこうなる。

  1. あるフローの 最初の 1 パケットが来る → eSwitch は「知らんフローや」となり、ソフトの vSwitch に上げる (slow path)。
  2. vSwitch が「このフローはこの相手へ」と判断し、そのルールを eSwitch に焼き込む。
  3. 2 パケット目以降は eSwitch がハードだけで捌く。CPU に上がらない (fast path)。

この「頭 (control plane) はソフトのまま、data plane だけハードに降ろす」分担は、NVIDIA の ASAP² 技術が「データパスを NIC embedded switch にオフロードし、control plane は素の OVS のまま」と明言している (NVIDIA DOCA: Virtual Switch on BlueField)。

eSwitch は結局、何をするのか

ここで最初の疑問 ── 「仮想基盤なしのベアメタルで、eSwitch は何をするんか」に答える。まず誤解を 1 つ外す。eSwitch は「ポートの間を振り分けるだけの L2 スイッチ」やない。

正体は、フロー 1 本ごとに match-action をハードで実行するデータパス。通す各フローに対して、ホスト CPU を経由せず次を適用する (NVIDIA DOCA):

  • ファイアウォール / ACL (通す・落とす) と、コネクション追跡 (conntrack)
  • オーバーレイの encap / decap (VXLAN・Geneve)
  • NAT・ヘッダ書き換え・QoS / レート制限・ミラー
  • 転送 ── 外の線へ出す (north-south)、別の VF へ折り返す (east-west)

だから「eSwitch を経由すること自体」に意味がある。通り道で、上のポリシーがまるごとハードでかかるからや。そしてこれは、接続先が 1 つ (単一 VM や単一 OS の通信 1 本) でも効く。実際、Azure の AccelNet が速くするのは VM 1 台 (＝ VF 1 つ) の通信で、VM どうしの振り分けとは関係ない。

PF / VF ──

PF (Physical Function) は物理 NIC そのものに対応する「本体の接続先」。VF (Virtual Function) は、その PF を分割して作る「独立した NIC のように見える軽い接続先」。1 枚の NIC を複数の接続先に切り分ける仕組みが SR-IOV。

じゃあ最初の疑問 ── 「ベアメタル単一 OS で eSwitch は要るんか」の答えは、何をオフロードしたいか次第や。

  • ホストの通信に、ハードのファイアウォール・NAT・オーバーレイ終端・QoS を効かせたいなら、単一 OS でも eSwitch にルールを積めば働く。
  • ルールを何も積まず素の NIC として使うだけなら、PF ↔ 外の線を素通しするだけ。ただしこれは「接続先が 1 つだからヒマ」やなくて 「eSwitch を使ってないからヒマ」。原因は接続先の数やなく、ポリシーを積んでいるかどうか。

図で見る

まず、居場所と材質。vSwitch はホスト OS の中のソフト、eSwitch は NIC の中のシリコン。役割は同じ。

vSwitch はホスト OS の中で動くソフト (コードはストレージ、実行は CPU)。eSwitch は PCIe で挿さった NIC カードのシリコンに焼かれた回路。居場所とハード / ソフトの材質がちがうだけで、役割はどちらも「相手のあいだのパケット転送」。

次に、両者がどう繋がるか ── 頭と筋肉の分業。最初の 1 個だけソフトに上がり、以降はハードで飛ぶ。

未知のフローの 1 個目だけ eSwitch → vSwitch へ上がり (slow path)、vSwitch がルールを eSwitch に焼き込む。2 個目以降は eSwitch の中だけで宛先へ折り返り、ソフト (CPU) を経由しない (fast path)。

最後に、eSwitch の転送アクションの一つ ── VF どうしの折り返し (east-west) には複数の VF が要るという話。単一 OS だと VF は 1 つで折り返す相手がいない。SR-IOV でコンテナに VF を配ると折り返せる。

左: 単一 OS では内側の VF が 1 つだけで、VF どうしの折り返し (east-west) は起きない (北←→南のポリシー処理は 1 つでもかかる)。右: SR-IOV で VF を作りコンテナに配ると、コンテナ間の通信 (east-west) を eSwitch がハードで折り返す。VM でなくコンテナでも絵は同じ。

混乱しやすいポイント

① 名前が紛らわしいだけで、別物やない

vSwitch も eSwitch も「スイッチ」。同じ役割の、ソフト版とハード版というだけ。eSwitch は vSwitch の data plane を NIC に降ろしたもの、と捉えると混乱しない。

② 「置き換え」ではなく「代行」

eSwitch が来ても、ルールを決める control plane はソフトの vSwitch が持ったまま。eSwitch はその判断を実行するだけで、頭が消えるわけやない。だから「AccelNet を有効にしたら VFP が要らなくなる」ではなく、「VFP は残って、実行だけ NIC に移る」が正しい。

③ コンテナだから自動でハード、ではない

仮想基盤 (VM) が無くても、コンテナを使えば相手を複数に戻せる。カギは SR-IOV や。

SR-IOV ──

1 枚の物理 NIC (PF) を、複数の VF に分割する仕組み。VF は「独立した NIC のように見える軽い PCIe デバイス」で、VM が無くても作れる。Kubernetes なら SR-IOV CNI プラグインが「Pod に VF を割り当てる」係をやる。

VF を 1 個ずつコンテナの network namespace に放り込むと、コンテナ A → コンテナ B の通信が、ホストのカーネルを経由せず eSwitch で折り返る。VM のときと絵が同じ ── eSwitch から見れば、上にぶら下がるのが VM かコンテナかは気にしない。

たとえ話

空港で一気通貫できる。

  • vSwitch (頭) ＝ 管制官。「どの便をどのゲートへ」を判断して指示を出す。頭脳労働で、人 (＝ CPU) がやる。
  • eSwitch (筋肉) ＝ 誘導路やゲートの物理的な分岐設備。管制官の指示どおりに、機体を実際に振り分ける。物理の設備 (＝ シリコン)。
  • 最初の 1 便だけ管制官に確認し (slow path)、以降は同じ経路を設備が自動でさばく (fast path)。
  • そして、分岐する先のゲートが 1 つしか無ければ、どれだけ立派な誘導路があっても振り分けようがない ── これが「相手が 1 つだと eSwitch がヒマ」の正体や。

用語の早見表

言葉つまり何の話？
vSwitchホスト OS の中で動くソフトのスイッチ (Open vSwitch・Linux bridge・Hyper-V vSwitch)。CPU を食う
eSwitchNIC のシリコンに焼かれたハードのスイッチ。CPU を食わない。役割は vSwitch と同じ
control plane (頭)どの相手へ・通す / 落とすを決める側。ソフト (vSwitch / VFP) の仕事
data plane (筋肉)決まったルールで 1 パケットずつ実際に転送する側。ハード (eSwitch) に降ろせる
slow path未知フローの 1 個目だけソフトに上げてルールを決める経路
fast path2 個目以降を eSwitch だけで捌く、CPU を経由しない経路
PFPhysical Function。物理 NIC 本体に対応する接続先
VFVirtual Function。PF を分割して作る「独立した NIC に見える」軽い接続先
SR-IOV1 枚の NIC を複数の VF に分割する仕組み。VM でなくコンテナにも配れる
east-west相手のあいだ (VM / コンテナ間) の横方向の通信。eSwitch が折り返す対象
AccelNetAzure の機能。VFP (頭) のルールを NIC の eSwitch (筋肉) に焼いてハードで飛ばす
次に答える、設計者の問い で、それがなんやねん？

で、コンテナのネットワークを ソフトスイッチのまま回すか、SR-IOV で eSwitch に載せるか？

  • bridge + veth でホスト CPU を使い続けるか、SR-IOV で VF を配って eSwitch に寄せるか。 分かれ目は「その CPU サイクルを本業の計算に空けたいか」と「Pod を別ホストへ気軽に動かしたいか」── VF 直結は速い代わりに可搬性を削る。
  • どちらを選んでも、誰とどの相手が繋がるかを決める control plane はソフト (OVS / VFP) のまま。ハードに降ろせるのは実際の転送 (data plane) だけ。この境界は AccelNet の切り分けと同じ。

これに答えられると強い ── SmartNIC を「挿せば速くなる箱」でなく、「どの処理をどこに置くかの設計変数」として語れる側に立てる。

深掘りメニュー 次におすすめのトピック

この記事の続きとして、未来の自分が次に掘るといいトピック。

  • SR-IOV の PF と VF (PCIe から見た正体) ── VF が「独立した NIC に見える」中身。switchdev と representor まで行くと、eSwitch の設定が腑に落ちる。
  • DPU (BlueField など) ── eSwitch の control plane ごと NIC 上の ARM に載せて、ホスト CPU をさらに解放する次の段。SmartNIC の一歩先。
  • slow path / fast path の 1 パケット目 ── 「最初の 1 個」で何が起きてルールが焼かれるか、の細部。