doca-public-knowledge-map

DOCA 公開ナレッジマップ

まず確認する場所：「正式な回答はどこにありますか？」という質問には、このスキルを参照してください。ドキュメントページ、ディスク上のインストールレイアウト、サンプル、または NGC カタログエントリーが対象です。まず ## Public documentation entry points を読み、次にユーザーの意図に合ったルーティングテーブルのセクションに進んでください。

このスキルの使い方。 このファイルを読み、続いて、質問に必要な ## <name> 見出しをコンパニオンファイル内で検索し、そのセクション全体を読んでください。そこに記載されたシンボルとコマンドのみを引用して、完全な回答を作成してください。ドキュメントを閲覧せず、doca-public-knowledge-map のエントリーポイントを使用してください。環境確認は、ユーザーの DOCA ホストで実行するコマンドとして提示してください。対象範囲外のリクエストには、その担当スキルの名前を伝えて終了してください。

このスキルを読み込むタイミング

DOCA のソースツリーにアクセスできない状況で、エージェントが正式な情報の所在を確認する必要があるNVIDIA DOCA に関する質問には、このスキルを読み込んでください。これには、DOCA のインストール、サンプルのビルド、DOCA ライブラリ（Flow、DPA、Comm Channel、GPUNetIO、…）の学習、エラーのデバッグ、API やエラーのリファレンスの検索、サンプルの検索、リリースノートや開発者フォーラムの確認などのドキュメントへの案内に関する質問が含まれます。このスキルは正式な回答の所在を確認します。実際のインストール、ビルド、チュートリアル、デバッグについては、フロントマターと ## Related skills に記載された、各ワークフローを担当するスキルに案内してください。

このスキルは、意図的にチュートリアルではなくルーティングテーブルとして構成されています。ユーザーの意図に合ったエントリーを選び、URL を取得するかローカルのインストールパスを確認してから、回答してください。

最初の確認 — 詳しく案内する前に尋ねる4つの質問

ユーザーが自由形式の案内を求めて会話を始めた場合（「DOCA を使うのは初めてです。どう始めればいいですか？」、「案内してもらえますか？」、*「DOCA を試す最も簡単な方法は何ですか？」*など）、エージェントには、進むべき道筋を選ぶための情報がまだ足りません。詳しい案内に入る前にこの4つの質問をすれば、ユーザーの環境では実行できない提案に時間を費やさずに済みます。短いメッセージ1通にまとめて尋ね、1問ずつ問い詰めないでください。

質問	重要な理由	振り分け先
1. 使用している OS は何ですか？ macOS、Windows、Linux ノート PC、クラウド VM、ラボの Linux マシン、BlueField OS 自体などですか？	DOCA をネイティブにインストールできるのは、サポート対象の Linux ディストリビューションだけです。macOS / Windows ユーザーはインストールできません。	doca-setup ## no-install の4つの DOCA 入手経路から選びます（doca-setup/TASKS.md#no-install）。macOS / Windows / Linux 環境なし → Path 0（NGC コンテナー）。サポート対象の Linux → Installation Guide に従って Path A または B。
2. どのようなハードウェアをお持ちですか？ NVIDIA ハードウェアなし、ConnectX SmartNIC、ホストに SmartNIC として搭載された BlueField、スタンドアロン DPU としての BlueField、または不明ですか？	実トラフィックを扱うランタイムには実際の NIC が必要ですが、ビルド、参照、学習には必要ありません。ユーザーのハードウェアによって、関連する DOCA ライブラリが決まります。	ランタイムに関する案内を決めます（ハードウェアがない場合、コンテナーでできるのはビルドのみです）。学習するライブラリの候補を絞ります（Flow で目に見える動作をさせるには実際のポートが必要です。Comch にはホスト ↔ DPU の組み合わせが必要です）。
3. 何をしたいですか？ 試しに使ってみたい、特定のライブラリ（Flow / RDMA / Comch / Telemetry / GPUNetIO / DPA / …）で最初の小さなアプリを作りたい、既存のリファレンスアプリケーションを実行したい、サービス（DMS / DTS / BlueMan / Firefly）を運用したい、またはその他ですか？	バンドルの最初のアプリ開発ワークフロー（doca-programming-guide ## modify）では、同梱の C サンプルから始めて、必要な部分を編集します。適切なサンプルは、ユーザーが対象とするライブラリによって異なります。	次に読み込むライブラリのスキルがあれば、それを選びます。ユーザーがまだ使うライブラリを決めていない場合、それ自体が振り分けに必要な回答です（上の ライブラリおよびモジュール別ガイド の表を参照し、ユーザーに選んでもらいます）。
4. どの言語でプログラムを書く予定ですか？ C / C++、Rust、Go、Python、その他ですか？	DOCA の公開インターフェースは C ABI です。C 以外の言語から利用する場合は、FFI / 言語バインディングを介します（doca-programming-guide CAPABILITIES.md ## Capabilities and modes およびライブラリ別スキルを参照）。ユーザーが C 以外の言語を使う場合も、C サンプルが参考になります。	エージェントによる最初のアプリの案内を、C で直接ビルドするか、C ABI に対する FFI / バインディングを使うか選びます。ただし、エージェントが最初に案内するサンプルは変わりません。

自由形式の案内、インストール、ビルド、実行に関する提案がユーザーの環境に左右される場合は、この4つの質問による確認を行います。この場合、質問1～3への回答を得る前に、具体的なインストール経路、コンテナーのタグ、または実行可能なサンプルを絶対に勧めないでください（質問4は最初のアプリ開発ワークフローには必要ですが、基本的な案内には必要ありません）。純粋なドキュメント参照（URL、API リファレンス、サンプルの場所、バージョンの参照、古いリンクの確認）は、この確認を省略して直接案内します。ユーザーが必要な質問に答えられない、または答えたくない場合は、環境に依存するためどの提案ができないのかを伝え、安全な、バージョンに依存しない包括的なドキュメントへの案内だけを提示し、不明な値を推測しないでください。こうした確認をする前に具体的なコマンドを提示することは、DOCA の案内で最もよくある失敗です。

ユーザーが最初のメッセージですでに情報の一部を伝えている場合は、該当する質問への回答済みとして扱い、残りだけを尋ねてください。すでに聞いている情報を再度尋ねないでください。

トピック別「まず確認する場所」ルーティング表

ユーザーから質問された場合は、次のように案内します。

ユーザーの意図	まず確認する場所
「DOCA のインストール方法を教えてください」	Installation Guide と Downloads ページ（公開ドキュメントの参照先）。
「DOCA を使い始めるには、最初に何をすればよいですか」	ユーザーが BlueField とホストハードウェアを持っている場合は Developer Quick Start Guide。そうでない場合は doca-setup ## no-install（doca-setup/TASKS.md#no-install）の Path 0（NGC コンテナー）。選択には、初回の状況確認にある4つの質問を使います。
「BlueField が必要ですか。SmartNIC ですか。それとも DOCA-Host だけでよいですか」	Overview ページ（doca-overview/index.html）と、Installation Guide の DOCA installation profiles セクション。この2つのページでハードウェアを選択できます。バンドルがユーザーに代わって選択することはありません。
「ライブラリ X を使うには、どのパッケージが必要ですか」	まず Installation Guide のパッケージマトリックスのセクションを確認し、次にユーザーのシステムで pkg-config --list-all を実行して確認します。
「ライブラリ X を使うサンプルを見せてください」	インストール済みの場合は /opt/mellanox/doca/samples/doca_<X>/。そうでない場合は docs.nvidia.com/doca/sdk/ にあるライブラリ別ガイド（各ライブラリガイドには同梱サンプルが記載されています）。
「DOCA のサンプルをビルドする方法を教えてください」	ライブラリガイドと、/opt/mellanox/doca/samples/... 内にあるサンプル独自の meson.build。
「X の API は何ですか」	ライブラリガイドを確認し、$(pkg-config --variable=includedir doca-common) の下にあるヘッダーを調べて確認します（通常、DOCA 3.3 以降では /opt/mellanox/doca/include/、レガシーまたは分割プロファイルのインストールでは /opt/mellanox/doca/infrastructure/include/）。
「pkg-config が doca-... を見つけられず、ビルドに失敗するのはなぜですか」	まず「Layout of an installed DOCA package」（PKG_CONFIG_PATH）を確認し、次に環境の準備とデバッグのために doca-setup/SKILL.md を読み込みます。環境を黙って変更しないでください。
「最新バージョンは何ですか。何が変わりましたか」	Release Notes。
「新しい DOCA はありますか。アップグレード、ダウングレード、ロールバックすべきですか」	検出 → 報告 → 確認 → ガイド付きアップグレードの手順（自動アップグレードはしない）については doca-upgrade/SKILL.md を確認します。対象リリースの内容については Release Notes を確認します。
「依存しているコンポーネントは提供終了または非推奨になりますか」	doca-upgrade/SKILL.md の提供終了確認を経由して、Release Notes（ライフサイクル／非推奨に関する通知）を確認します。記憶を頼りに非推奨だと断定しないでください。
「DOCA のバージョン番号は何を意味しますか。LTS は引き続きサポートされていますか」	Compatibility Policy（公開ドキュメントの参照先テーブル）。
「Kubernetes で DOCA を実行する方法や、DPU をプロビジョニングする方法を教えてください」	GitHub の DOCA Platform Framework。
「説明できない動作が起きています」	まず Release Notes（既知の問題）を確認し、次に DOCA Developer Forum を確認します。最初にフォーラムを確認しないでください。
上記に該当しない意図	references/map.md にある DOCA SDK インデックスと Libraries / Services / Tools の総合ページ（公開ドキュメントの参照先）から始めます。正式な参照先が見つからない場合は、その旨を伝えて Developer Forum を利用します。URL やコンポーネント名を捏造しないでください。

このスキルが意図的に扱わない内容

このファイルはチュートリアルではなく、意図的にマップとして作られています。次の内容は含みません。

• DOCA ライブラリのチュートリアル（ライブラリ別ガイドに記載されています）。
• API リファレンス（ヘッダーとライブラリ別ガイドに記載されています）。
• ビルドシステムの詳細解説（Installation Guide とサンプルの meson.build ファイルに記載されています）。
• パフォーマンス調整、ドライバーレベルのセットアップ、OFED との連携（Installation Guide とライブラリ別ガイドに記載されています）。

エージェントがこれらの情報を必要とする場合は、該当する公開ドキュメントを取得するか、該当するインストール済みファイルを読み込む必要があります。より特化したスキルが追加された場合は、バンドルの SKILLS.md に記載し、「確認する場所」を調べる際にここへ戻れるようリンクしてください。

関連スキル

環境の準備（インストールの確認、ビルド環境 （pkg-config、ヘッダー、hugepages、devlink）、環境クラスのデバッグ、 および DOCA を使っていない macOS、Windows、Linux のすべてのユーザー向けに、 カタログの Tags ページにある公開 NGC DOCA コンテナーを Stage 1 の汎用フォールバックとして使う まだインストールしていません の手順）には、 doca-setup/SKILL.md を読み込みます。このスキルは 「インストールが正常で、環境の準備ができている」 ところまでを扱います。

すべてのライブラリに共通する一般的な DOCA プログラミングパターン （標準的な pkg-config doca-<library> ビルドパターン（C/C++ の直接利用、 または FFI を介した非 C 言語での利用）、同梱サンプルから カスタムの最初のアプリを作成する汎用ワークフロー、汎用ライフサイクル （cfg-create → init → start → use → stop → destroy）、ライブラリ間で共通する DOCA_ERROR_* の分類、およびプログラム側のデバッグ順序）には、 doca-programming-guide/SKILL.md を読み込みます。各 ライブラリのスキルは、ライブラリ固有のオーバーライドを含めて、 ## modify（最初のアプリの作成）を拡張します。

DOCA Flow の内部機能（ポートと representor のセットアップ、パイプの作成、 match/action の仕様、ハードウェアへのプログラミング前のパイプ検証、 Flow カウンターとトレース、Flow のバージョン互換性、 および Flow API に起因する DOCA_ERROR_* エラーのデバッグ）には、 doca-flow/SKILL.md を読み込みます。このスキルは、共通のドキュメント案内と インストールレイアウトの確認にこのスキルを、環境の準備に doca-setup を、また基盤となるライブラリ間共通のプログラミングパターンに doca-programming-guide を利用できることを前提としています。

実行中のシステムを対象とする具体的なローカルデバッグのループ （インストール済みホストでのビルド、リンク、または実行時エラーの再現、 コンポーネントの特定、およびその修正の反復）については、 doca-debug/SKILL.md が編集・実行・観察のサイクルを担い、 このスキルと併せて読み込む必要があります。このサイクルを引き継いだからといって、 情報提供を控えてよいわけではありません。デバッグの回答でも、 このスキルが担う次の 2 つの情報を引き続き提示する必要があります。 つまり、サンプル、ライブラリ、pkg-config ファイルの実際の場所を示す /opt/mellanox/doca/... のインストールレイアウトと、 該当ライブラリの標準的な docs.nvidia.com ページです。 例外として、ユーザーがドキュメントはすでに手元にあり、ローカルデバッグのループだけが必要だと述べた場合は、 doca-debug と対応するコンポーネントスキルに案内して終了します。 このスキルも読み込むよう伝えてはいけません。

例

このスキルが案内する質問の形式は、references/map.md にあります。

手順

まずこのファイルを読み込みます。その後、references/ 配下にある対応する関連ファイルのみを開きます。 ファイルは 1 つだけで、ディレクトリ全体を開いてはいけません。同じ回答のために 2 つ目の関連ファイルを参照してはいけません。

質問の分類	references/ 配下で開くファイル名
質問の例、GitHub ソース、ディスク上のレイアウト、バージョン、URL の監査、基本ルール、ドキュメントの入口	map.md
ライブラリごとの公開ガイド	libraries.md
バンドルに含まれる DOCA サービス	services.md
バンドルに含まれる DOCA ツール	tools.md
外部製品として提供される DPU、サービス、ファブリック、オーケストレーション、またはファームウェア製品	external-dpu.md

これらのファイルにはそれぞれ、回答ではなく案内を行うための 3 部構成の契約 （分類を認識し、境界を示し、公開 URL を提示する）が記載されています。 関連ファイルをすべて開いてはいけません。ファブリック、オーケストレーション、ファームウェア、 スイッチ製品については、external-dpu.md から始め、最後のセクションに従ってください。

公開ドキュメントの入口

公開ドキュメントの入口をまとめた表は、 references/map.md の最後のセクションにあります。

公開ソースコード：GitHub

公開されている GitHub ソースの場所は、 references/map.md ## Public source code: GitHub に記載されています。 リポジトリの URL を捏造してはいけません。

インストール済み DOCA パッケージのレイアウト

ディスク上の /opt/mellanox/doca のレイアウト表は、 references/map.md ## Layout of an installed DOCA package にあります。 該当する関連ファイルを読み込み、記憶を頼りにインストールパスを捏造してはいけません。

バージョンの確認場所

バージョン検出のルーティングは、 references/map.md ## Where to find the version にあります。 4 つのソースをたどる手順については、doca-version/SKILL.md を読み込んでください。

URL の監査

インライン URL 監査の履歴は、 references/map.md ## URL audit にあります。 古いリンクの復旧に関する情報はこのファイルではなく、そちらに記載してください。

ライブラリおよびモジュール固有のガイド

ライブラリごとの公開ガイドの一覧は、 references/libraries.md にあります。 単一ライブラリのドキュメントへのルートを確認するには、こちらの関連ファイルを開いてください。

DOCA サービス

バンドルに含まれる DOCA サービスのガイド一覧は、 references/services.md にあります。 DMS / Firefly / Argus / UROM サービスのドキュメントへのルートを確認するには、こちらの関連ファイルを開いてください。

DOCA サービスの大規模デプロイ

フリート／Kubernetes オーケストレーションは、このバンドルの SDK の対象範囲外です。 ペルソナ／規模別のエントリーポイントは、 references/services.md にあります。 この規模でホストごとに bfb-install のループを手作業で作成しないでください。

DOCA ツール

バンドルに含まれる DOCA ツールのガイド一覧は、 references/tools.md にあります。 caps / bench / tune / tracer のドキュメントへのルートを確認するには、こちらの関連ファイルを開いてください。

外部製品化された DOCA ソフトウェア — このバンドルには含まれませんが、ルーティング先はこちらです

26 製品の「ルーティング先案内であり、回答ではない」表は、 references/external-dpu.md から始まり、ファブリック、オーケストレーション、ファームウェア、 スイッチ製品を扱う最後のセクションまで続きます。 該当する分類を認識し、モノレポの境界を明示したうえで、公開 URL と Developer Forum の検索ヒントを案内してください。トレーニングデータの知識から、これらの製品について情報を作り出さないでください。