2399177_ja-JP

是

MPLS内部IP上のDPAA2 DPDK RSSハッシュ

こんにちは、

SolidRun LX2160A Clearfog CXでDPDKを使ってDPAA2のRSS機能をテストしています。
例えばMPLSラベルやPPPoEの内部IPでハッシュ化できることがわかりました。
しかし、MPLS内部IPアドレスに対してハッシュ化できないようですが、私の理解は正しいでしょうか？
これは少し驚きました。なぜなら:
- MPLSヘッダーが何かを知っているのは、MPLSラベル上でハッシュ化できるからです
- PPPoEの内側IPをハッシュ化できるため、内部IPを取得する方法を知っています

MPLSの内部IPでハッシュ化がサポートされているかどうか確認してもらえますか?

私はNXP DPAA2やNXP全般についてかなり初心者なので、技術的な言葉を教えてもらえますか?

ありがとうございます。

Re: DPAA2 DPDK RSS Hash on MPLS Inner IP

はい — あなたの理解は、今日testpmdで使われているDPDK DPAA2 PMDに関して正しいです。MPLSラベル自体でのハッシュ処理はサポートされており、PPPoE後の内側IPでのハッシュも動作しますが、MPLSの内側IP RSSはすぐに使えるDPDK RSSモードとして明確に公開されていません。

重要なニュアンスは次のとおりです。

DPAA2ハードウェアは十分に対応可能です。LX2160AパーサーはMPLSを認識し、MPLSラベルスタックを通り抜け、特定の条件下でIPv4/IPv6へと解析を続けることができます。
DPAA2鍵抽出には「内側/最終IP」フィールドもあります。分配鍵機構ではHDR_INDEX = 0xFF 、つまり「最も内側/最後のヘッダー」を用い、ハードウェアは最後のIPヘッダーに対してIPSRC_N / IPDST_Nを定義します。
しかし、公開されたDPDK DPAA2 PMDドキュメントでは、RSSが一般的にサポートされているとのみ記載されており、固定RSSキーや設定不可のRETAなどの制限が記載されています。サポートされているRSSの組み合わせではありません。Linux/SDK向けのハッシュドキュメントには、イーサネット宛先、VLAN、L3プロトコル、IPv4の送信元/送信先、L4ポートなどの通常のフィールドが記載されていますが、「MPLS後のIP」は選択可能なハッシュモードとして記載されていません。

つまり、シリコンの制限ではなく、あなたが使っているDPDK DPAA2 PMDパスのソフトウェアやドライバー露出制限が原因だと思います。

試せることは

まず、DPAA2がパケットを「MPLS + 内部IP」として認識していることを確認してください。

ハードウェアパーサーが内部のIPv4ヘッダーを存在としてマークしない場合、内部IP上のRSSは動作しません。

DPDKで、DPAA2 PMDログを有効にします。

コピー

--log-level=pmd.net.dpaa2:debug

また、受信パケットがアプリケーション内やtestpmdで意味のあるパケットタイプ情報を得られるかどうかも確認してください。例えば、パケットがMPLSのみに分類されているのか、MPLSと内なるIPv4として分類されているのかなどです。

パケットタイプがMPLSで終了すると、ドライバの観点からは内部IPv4が解析されていないため、RSSハッシュは内部IPv4を使用できません。

フローパターンを明確にしてみてください

RSSタイプをmplsのみに設定した場合、MPLSフィールドは自動的にハッシュ化されます。内部IPv4ヘッダーを明示的に含むパターンを試してください。

コピー

フロー作成 0 イングレス \

パターン eth / mpls / ipv4 / end \

アクション RSS キュー 0 1 終了タイプ IPv4 終了 / 終了

送信元/宛先IPアドレスを具体的に知りたい場合は、以下も試してみてください。

コピー

フロー作成 0 イングレス \

パターン eth / mpls / ipv4 / end \

アクション RSS キュー 0 1 終了タイプ IP IPv4 終了 / 終了

それが拒否または承認されたにもかかわらず、内部 IPv4 アドレスに基づいて配布されない場合は、PMD が DPAA2 配布キーを「最後の/内部 IP」としてプログラムしていない可能性があります。

パーサーを助けるMPLSラベル値を試してみてください

MPLSトラフィックが通常のサービスラベルを使用している場合、パーサはペイロードがIPv4であることを認識しない可能性があります。制御テストとしては、MPLSの明示的NULLラベルを試してください:

MPLSラベル0はIPv4明示的NULLを意味します。
MPLSラベル2はIPv6の明示的NULLを意味します。

DPAA2のドキュメントによると、MPLSラベル解釈が有効の場合、ラベル0はIPv4に、label2はIPv6にマッピングされます。

もし内側IP上のRSSがラベル0でのみ動作する場合、問題はRSS自体ではありません。問題は、パーサーがMPLSペイロードがIPであることを知らなかったことです。

この機能が必要な場合、本当の解決策はPMDの作業である可能性が高いです。

DPAA2ハードウェアには、これに必要な概念が備わっています。

HDR_INDEX = 0xFF は「最も内側のヘッダーを使用する」ことを意味します。
IPSRC_NとIPDST_Nは、最後のIPヘッダーの送信元/宛先アドレスです。
MPLSパーサーは適切に設定すればMPLSを超えてIPへと進むことができます。

したがって、ドライバーレベルの実装では、DPNIの配信プロファイルを以下のようにプログラムする必要があるでしょう:

内部/最後の IPv4 送信元アドレス、
内部/最後の IPv4 宛先アドレス、
おそらく内部L4ポート、
MPLS解析パスの後。

実際には、これは単にtestpmdコマンドを変更するだけでなく、DPAA2 DPDK PMDを変更する必要があるかもしれません。

私の結論として、DPAA2ハードウェアは原則として「内側/最終IP」フィールドに到達できますが、MPLS-inner-IP RSSはスタック上で既にサポートされているDPDK DPAA2 PMD機能ではないようです。もし明示的なeth / mpls / ipv4のRSSルールが失敗した場合、別のtestpmdコマンドではなくPMD/パーサー/配布プロファイルの変更が考えられます。