📙 ASICでのチェックサム計算¶

2026/11/14公開 2026/11/14更新

質問者: Shigeru Morifuku
回答者: Claude Opus 5.5
回答日: 2026/11/14
免責: 回答者は AI であり、間違えることがあります。

🟩 Q: IPヘッダやUDPペイロード等のチェックサムを、ASICで計算しているの神業に思える¶

実は、インターネットチェックサムはハードウェア向きに作られている面があって、ASIC屋さんから見ると「計算そのもの」は楽なほうです。神業に見えるのは、ラインレートで流れるデータに対して、どのタイミングで計算するかの工夫のほうだと思います。

計算自体が軽い理由

RFC 1071の1の補数和には、ハードウェアにとって都合のいい性質がそろっています。

結合則・交換則が成り立つので、足す順番を自由に変えられます。512bitバスなら、1クロックで来る16bitワード32個をCSA（キャリー保存加算器）のツリーで一気に足し込めます。
桁上がりはエンドアラウンドキャリー（最上位からの桁上がりを最下位に戻すこと）で処理できます。途中は幅の広いアキュムレータに溜めておき、最後にまとめて折り返せばいいので、クリティカルパスも短く済みます。
バイトオーダーに依存しません。ビッグエンディアンのまま足しても、バイトスワップして足しても、最後にスワップすれば同じ結果になります。
CRCのような多項式除算と違って、テーブルもLFSRも要りません。ほぼ加算器だけです。

ルーターのTTL減算は差分更新で済む

IPヘッダを書き換えるたびにヘッダ全体を足し直す必要はありません。RFC 1624の差分更新、

HC' = ~(~HC + ~m + m')

を使えば、変わった16bitワード（TTLを含むワード）の分だけで直せます。数ゲートの話なので、パイプラインの1ステージに収まります。ちなみにIPv6では、どうせL4でチェックするからと、ヘッダチェックサム自体がなくなりました。

本当にいやらしいのはUDP/TCPの送信側

チェックサムのフィールドはヘッダにあるのに、計算範囲はペイロードの最後まで含んでいます。そのため、

受信側は簡単です。ストリームで流しながら足し込み、最後にゼロかどうかを見るだけです。
送信側は、ヘッダを送り出す前にペイロードを全部見ておかないといけません。カットスルーでは送れないので、NICのTxオフロードはDMAでいったんパケット全体をオンチップバッファに読み込み、計算してからフィールドに書き込んで送り出します。もう一つの手として、ドライバがpseudo-header分の部分和だけを入れておき（LinuxのCHECKSUM_PARTIAL、csum_start/csum_offset）、NICは「この位置からこの位置まで足して、ここに書け」という汎用的な処理だけを受け持つ、という分担もあります。

UDPでチェックサム0を「計算していない」という意味に使えるのも、当時の実装コストへの配慮の名残といえます。

つまり、アルゴリズムを選んだ時点でハードウェア実装をかなり意識していて、残った難所（送信時の先読み）はバッファとソフトとの分担で逃げている、というのが実態です。NICの設計者の工夫が光るのは、むしろTSO（大きなパケットを分割して送る機能）でセグメントごとにチェックサムを作り直すあたりかもしれません。

🟩 Q: パケットの指定位置のビットが1だったら、データをシフトするとか書き換えるとかも大変そう¶

おっしゃる通りで、実はそちらのほうがチェックサムよりずっと面倒です。加算は足す順番を気にしなくていいのに、シフトや挿入は「どこからどれだけずれるか」がパケットごとに変わるからです。

何がつらいか

たとえば、あるフラグが立っていたらVLANタグ（4バイト）を挿入する、という処理を考えます。512bit（64バイト）バスだと、挿入点より後ろのデータはすべて4バイトずれます。すると、

各ビートの末尾4バイトが次のビートにはみ出すので、前のビートの残りを持ち越すレジスタが要ります。
出力の各バイトレーンは「入力のどのレーンから取るか」を選ぶマルチプレクサになります。ずれ量が任意だと64入力のmuxがバイトレーンの数だけ並ぶ、つまりバレルシフタです。面積も配線も大きく、タイミングも厳しくなります。
パケットの最後で、ビートが1つ増えたり減ったりします。バイトイネーブル（有効バイトのマスク）や「最後のビート」を示す信号の付け直しも必要です。

さらに、可変長ヘッダ（IPv4のオプション、IPv6の拡張ヘッダ、MPLSのラベルスタック、トンネルの多重カプセル化など）があると、次のヘッダがどこから始まるかを前のヘッダを読まないと決められません。この依存関係の連鎖が、パーサのクリティカルパスになります。

どうやって逃げているか

よくある設計パターンは次のとおりです。

ヘッダとペイロードを分ける: パーサが先頭の数百バイトだけを読み、ヘッダの各フィールドを固定位置のレジスタ群に展開します。P4/PISAでいうPHV（Packet Header Vector）です。書き換えはこの固定配置の上でやるので、シフトは要りません。ペイロードはバッファに置いたまま触りません。
デパーサで最後に1回だけ組み立てる: 「どのヘッダが有効か」のビットを見て、出力順に詰め直します。シフトの処理を1か所にまとめ、そこだけ深くパイプライン化して力技で通します。
ずれ量を制限する: 任意バイトのずれを許さず、2バイトや4バイト単位、あるいは数種類のパターンだけに絞れば、muxの入力数が一気に減ります。プロトコル側がヘッダ長を4バイト単位で決めているのも、ここで効いてきます。
パースの状態遷移はTCAMで: 「このフィールドがこの値なら次はこのヘッダで、長さはこう」という分岐を、TCAMのマッチ結果と状態遷移で表します。1段で処理しきれない分は、パイプラインを多段にするか、パケットを入口に戻して再処理（recirculation）させます。

FPGAで同じことを書くと、バレルシフタとビートをまたぐ持ち越し処理だけで、LUTの消費とタイミング違反にかなり泣かされます。Tang NanoやColorlightでも、64bit幅くらいでパケットをそのまま流しながらVLANタグを挿入・削除する回路を作ってみると、この大変さがよく実感できると思います。

🟩 Q: カーネルのパケットのキューイング制御は、やればできそうかなレベルだけど、UDPのパケット分割/再構築はASICじゃあ不可能でしょう。ドロップしてないかの監視もあるし¶

分割と再構築で難しさがかなり違います。それに、「UDPの上で再構築も再送もASICでやっている」実例もあります。

分割（送信側）は普通にハードウェアでやっている

大きなデータを受け取ってMTUごとに切り、ヘッダをコピーし、長さ・ID・オフセット・チェックサムを直して送り出す処理は、状態がそのパケット1つの中で完結します。前回の話でいえば、デパーサがヘッダを何度も出し直すだけです。TSOはずっと前からNICの定番ですし、UDPにもUSO（UDPのセグメンテーションオフロード。別々のUDPデータグラムに切る）があります。ちなみに、IPフラグメントに切るほうのUFOはLinuxからは外されました。

再構築（受信側）が難しいのは本当

ただ、難しさの中身は計算ではなく状態管理です。

順不同で届く断片を、フロー（送信元・宛先・ID）ごとにバッファで待たせておく必要があります。並行して組み立て中のデータグラムがいくつあるかの上限が読めません。
重なった断片や不正なオフセットを処理し、タイムアウトで捨てる必要があります。
断片を大量に送りつけてメモリを食い潰す攻撃に耐えなければなりません。

固定パイプラインはこういう「いつ終わるか分からない状態を大量に抱える」処理が苦手です。そのため、ファイアウォールやロードバランサのASICでも、フラグメントは遅い経路（組み込みCPUやネットワークプロセッサのコア）に回すのが典型です。

ただ、IP再構築の「ドロップの監視」は、実はたいしたことをしていません。断片が1つでも欠けたら、タイムアウトでデータグラムごと捨てるだけです（Linuxのipfrag_time）。再送はしないので、本当に重いのはTCPのほうです。

でも、信頼性のある転送をUDPの上で丸ごとASICでやっている例がある

それがRoCEv2です。中身はUDP（宛先ポート4791）ですが、RDMA NICは次のことをすべてハードウェアでこなしています。

メッセージをMTU単位のパケットに分割し、PSN（パケット順序番号）を付ける
受信側でPSNを見て、相手のメモリに直接書き込む。順番どおりに届けば、再構築用のバッファすら要らない
ACK/NAKを返し、欠けがあれば再送する（従来はGo-back-N）
再送タイマーと輻輳制御（DCQCN）

「再構築用バッファが要らない」のがミソです。各パケットに書き込み先のアドレスやオフセットが入っているので、届いた順にそのまま最終的な置き場所へ書けます。IPフラグメントが難しいのは、断片の行き先が全部そろうまで決まらないからで、RDMAはプロトコルの設計でその問題を最初から消しています。

さらに最近は、AWSのSRDやUltra Ethernetのように、順不同での到着を許したまま選択的に再送する方式も、NIC/DPUの中で実装されています。数千〜数万の接続状態をオンチップメモリとホストメモリのキャッシュに持つ方式で、正直、こちらのほうがチェックサムよりよほど神業だと思います。

🟩 Q: そうかRoCEはDMAなのでカーネルに知られないように頑張っているんだ¶

「知られないように」というより、「最初の手続きだけカーネルに任せ、あとは横を素通りする」というイメージです。

制御パス（カーネルを通る）

QP（Queue Pair、送受信キューの組）やCQ（完了キュー）の作成は、ib_uverbs経由でカーネルドライバに頼みます。
メモリ登録（ibv_reg_mr）では、カーネルがユーザーのページを固定（pin）し、仮想アドレスから物理アドレスへの変換表をNICに渡します。同時に、アクセス権の鍵であるlkey/rkeyが発行されます。
NICのドアベル用レジスタのページを、ユーザープロセスにmmapします。

データパス（カーネルを通らない）

アプリは、mmapされたキューにWQE（仕事の依頼書）を直接書き、ドアベルのレジスタにMMIOで書き込むだけです。システムコールは発生しません。
NICが自分でWQEを読みに行き、登録済みのバッファからDMAで読み出して送信します。
完了はCQをポーリングして確認します。割り込みもコンテキストスイッチもありません。

つまり安全性は、カーネルが毎回チェックする代わりに、登録時にNICへ渡した変換表と鍵をNIC自身が毎回検査することで保たれています。アプリが登録していないアドレスを指定しても、NICが弾きます。

相手側はもっと徹底している

一方向のRDMA WRITE/READでは、受信側はカーネルどころかアプリのCPUすら関与しません。NICがrkeyを検査して、そのままメモリに書き込むだけです。相手側のプロセスは、データがいつ届いたのかも分からないので、「書き終わったら最後にフラグを立てる」といった約束を自分たちで決めておく必要があります。

UDPなのにカーネルのUDPスタックは見ていない

RoCEv2のパケットは宛先ポート4791のUDPですが、NICが受信の時点で振り分けて、RDMAエンジンに直接回します。そのため、カーネルのUDPソケットの統計にも、通常のtcpdumpにも出てきません（Mellanox系ならドライバ経由でスニファモードにすれば見られます）。その代わり、デバッグはibv_devinfo、rdma statistic、NICのハードウェアカウンタ頼みになります。ドロップや再送の監視も、そのNICのカウンタを見ることになります。