登録済みメモリのキャッシュ
SAN サービス プロバイダーは、ローカル またはリモート アクセス用に公開されている RDMA バッファーをキャッシュして、パフォーマンスを向上させることができます。
ローカル アクセス用に公開されている RDMA バッファーのキャッシュ
Windows ソケット スイッチは、アプリケーションの代わりに SAN サービス プロバイダーの WSPRegisterMemory 拡張機能関数を呼び出して、 WSPRdmaRead 拡張機能関数の呼び出しで、ローカル受信 RDMA バッファーとして、または WSPRdmaWrite 拡張関数への呼び出しのローカル RDMA ソースとして機能するすべてのデータ バッファーを登録します。 この登録プロセスの一環として、SAN サービス プロバイダーは、これらのバッファーを物理メモリーの領域にロックダウンし、SAN NIC に登録する必要があります。 これらの操作はどちらもリソースを集中的に消費します。 そのため、SAN サービス プロバイダーは、これらの登録のオーバーヘッドを減らすためにキャッシュを使用する必要があります。 SAN サービス プロバイダーがキャッシュを使用する場合、データ転送にバッファーを再利用するアプリケーションのパフォーマンスが向上します。
SAN サービス プロバイダーは、次の一覧で説明するように、ローカル アクセス用に公開されている RDMA バッファーをキャッシュして解放する必要があります。
スイッチが WSPDeregisterMemory 拡張関数を呼び出してバッファーを解放する場合、SAN サービス プロバイダーは、バッファーを SAN NIC に登録したままにし、物理メモリーの領域にロックダウンする必要があります。 また、SAN サービス プロバイダーは、後続の RDMA 操作でバッファーが再び使用される場合に備えて、登録されたバッファーのキャッシュにバッファーを追加し、次のリスト項目で説明されているようにバッファーの所有を保護する必要があります。
SAN サービス プロバイダーは、仮想アドレスに基づいてメモリー登録をキャッシュします。 SAN サービス プロバイダーがバッファーの登録をキャッシュする場合、SAN サービス プロバイダーのプロキシ ドライバーは MmSecureVirtualMemory 関数を呼び出して、登録されているバッファーの所有を保護し、オペレーティング システムがバッファーが解放された場合にスイッチに通知するようにします (たとえば、アプリケーションが VirtualFree 関数を呼び出して仮想アドレス範囲をオペレーティング システムに解放する場合)。
スイッチが後で WSPRegisterMemory を呼び出してバッファーを登録する場合、SAN サービス プロバイダーはキャッシュをチェックして、バッファーが既に登録されているかどうかを判断する必要があります。 SAN サービス プロバイダーがそのキャッシュ内にバッファーを検出した場合、SAN サービス プロバイダーはそれ以上登録アクションを実行しないはずです。
登録されたバッファーの仮想から物理へのマッピングが次に変更される前に、スイッチは各 SAN サービス プロバイダーの WSPMemoryRegistrationCacheCallback 拡張関数を呼び出します。 さらに、各 SAN サービス プロバイダーのプロキシ ドライバーは、MmUnsecureVirtualMemory 関数を呼び出してバッファーの所有権を解放する必要があります。 さらに、各 SAN サービス プロバイダーは、キャッシュからバッファーを削除し、SAN NIC からバッファー登録を削除する必要があります。
ローカル SAN ソケットとリモート ピアの間の接続を閉じる前に、SAN サービス プロバイダーはキャッシュされたバッファーを解放する必要があります。
注: プロキシ ドライバーは、オペレーティング システムのクラッシュを防ぐために MmSecureVirtualMemory の呼び出しによって確保されたユーザー モード バッファーにアクセスするコードに関する try/except メカニズムを使用する必要があります。 プロキシ ドライバーがバッファーを確保および解放する方法の詳細については、「仮想アドレスの所有権のセキュリティ保護と解放」を参照してください。
リモート アクセス用に公開されている RDMA バッファーのキャッシュ
Windows ソケット スイッチは、SAN サービス プロバイダーの WSPRegisterRdmaMemory 拡張機能関数を呼び出して、リモート WSPRdmaWrite 呼び出しのリモート RDMA ターゲットまたはリモート WSPRdmaRead 呼び出しのリモート RDMA ソースとして機能するすべてのデータ バッファーを登録します。 つまり、スイッチは、リモート ピアによるアクセスのためにこれらのバッファーを公開します。 これらのバッファーからのデータ転送が完了すると、スイッチは SAN サービス プロバイダーの WSPDeregisterRdmaMemory 拡張機能関数を呼び出して、リモート ピアからアクセスできないようにこれらのバッファーを解放します。
SAN サービス プロバイダーは、次の一覧で説明されているリモート アクセス用に公開されている RDMA バッファーをキャッシュする必要があります。
スイッチが WSPDeregisterRdmaMemory を呼び出してバッファーを解放する場合、SAN サービス プロバイダーはバッファーを物理メモリーでロックしたままにし、SAN NIC に登録する必要があります。 SAN サービス プロバイダーは、後続の RDMA 操作でバッファーが再び使用される場合に備えて、登録されたバッファーのキャッシュにバッファーを追加する必要もあります。 ただし、SAN サービス プロバイダーは、リモート ピアがバッファーにアクセスできないように、適切なアクションを実行する必要があります。 注: SAN サービス プロバイダーが SAN NIC からバッファー登録を削除することによってのみバッファーにアクセスできないようにできる場合は、SAN サービス プロバイダーがアクセスできないようにする必要があります。 ただし、SAN サービス プロバイダーは、バッファーを物理メモリーの領域にロックしたままにする必要があります。 このシナリオでは、可能な限り最高のパフォーマンスは提供されませんが、キャッシュがない場合よりも優れています。
リモート アクセス用に公開されている RDMA バッファーをキャッシュするには、SAN サービス プロバイダーとそのプロキシ ドライバーは、ローカル アクセス用に公開されている RDMA バッファーについて前の一覧で説明されるとおりに、キャッシュ手法を使用する必要があります。
スイッチが後で WSPRegisterRdmaMemory を呼び出してバッファーを登録する場合、SAN サービス プロバイダーはキャッシュをチェックして、バッファーが既に登録されているかどうかを判断する必要があります。 SAN サービス プロバイダーがキャッシュ内のバッファーを見つけた場合、SAN サービス プロバイダーはリモート アクセス用のバッファーを公開するだけで、それ以上の登録操作は必要ありません。 ただし、バッファー登録が以前に SAN NIC から削除された場合、SAN サービス プロバイダーはバッファーをもう一度登録する必要があります。
リモート アクセス用に公開されている RDMA バッファーを解放するには、SAN サービス プロバイダーとそのプロキシ ドライバーで、前の一覧で説明した手法を使用する必要があります。