QorIQプロセッサ用のLinux SDKには、ドライバーステージングツリーに qman_high.c が含まれています。これには、コメントで「読み取りが順番通りにQBManに到達することを保証し、//WRAPトランザクションがQBManに認識されないようにする//」と説明されている関数safe_copy_dqrr()が含まれます。
これは、DQRRインデックスラップとは関係なく、AXI WRAPバーストトランザクションのことを指していると思われます。
なぜこの問題が安全にしなければならないのか、誰か説明してもらえますか?
よろしくお願いします。
こんにちは、
はい、そのコメントはおそらくバス/キャッシュラインのWRAPトランザクションに関するものであり、DQRRプロデューサー/コンシューマーインデックスのラッピングに関するものではないと思われます。
「安全」である必要がある理由は、DQRRエントリが通常のRAMではないからです。これはQBManポータル構造であり、その内容はQManによって生成され、CPUキャッシュに隠され、ソフトウェアが VERBバイトの有効なビット を使って消費されます。DPAAマニュアルでは、QManがDQRRエントリを原子的に更新しても、GPPコアの読み取りがエントリのすべてのバイトが同時に変化するのを観測することはできないと記載されています。ソフトウェアは有効なビットを含むVERBバイトがDQRRエントリの他の部分より先に読み込まれることを確実にしなければなりません。
だから safe_copy_dqrr() この危険なパターンを避けようとしているのです:
CPU は DQRR エントリをコピーしたい - > コンパイラ / CPU / キャッシュサブシステムがそれをバーストまたはキャッシュラインの充填に変換 します - > トランザクションが QBMan に到達すると WRAP スタイル の リード - > QBMan / インターコネクトがある順序 で ビートを認識 ・ 読み取ることができます論理フィールドの順序 とは異なり - > ソフトウェアは、古いまたはまだ表示されていないエントリデータ に関連する 有効な 動詞 バイトを観察することがあります
これは有効なビットが同期点であるため重要です。DQRRエントリスタッシングを有効にすると、ドキュメントは関連するDQRRエントリスタッシュがプロセッサキャッシュに到達する前に更新され、レースが発生する可能性があると明 DQRR.PI 記しています。したがって、ソフトウェアは DQRR.PI ではなく、DQRRエントリ内の有効なビットを使って本番を検出すべきです。有効ビット自体は、リングが最後のエントリからエントリ0に戻るたびに極性が切り替わる交互極性ビットです。
よろしくお願いします。