Betreibt das NVIDIA RDMA GPUDIRECT immer nur physische Adressen (im physischen Adressraum der CPU)?

Question

Wie wir wissen: http://en.wikipedia.org/wiki/iommu#advantages

Periphere Speicherpaging kann von einem unterstützt werden Iommu. Ein Peripherieur, das die PRI-Erweiterung (PCI-Sig PCIe Address Translation Services) verwendet, kann die Notwendigkeit von Speichermanager-Diensten erkennen und signalisieren.

Aber wenn wir Nvidia gpu mit CUDA> = 5.0 verwenden, können wir RDMA GPUDirect verwenden und das wissen:

http://docs.nvidia.com/cuda/gpudirect-rdma/index.html#how-gpudirect-rdma-works

Traditionell werden Ressourcen wie Balkenfenster dem Benutzer- oder Kerneladressraum unter Verwendung der MMU der CPU als Speicher -zugeordnete E/A -Adressen (MMIO) zugeordnet. Allerdings, weil Aktuelle Betriebssysteme haben keine ausreichenden Mechanismen für den Austausch von MMIO -Regionen zwischen den Treibern, Die Exporte des Nvidia -Kernel -Treibers bewirkt, dass die erforderlichen Adressübersetzungen und -zuordnungen durchgeführt werden.

http://docs.nvidia.com/cuda/gpudirect-rdma/index.html#supported-systems

RDMA für gpudirect stützt sich derzeit auf alle physischen AdressenAus der Sicht der PCI -Geräte der gleichen. Dies macht es mit iommus unvereinbar und daher müssen sie für RDMA deaktiviert sein, damit gpudirect arbeiten kann.

Und wenn wir CPU-RAM der UVA zuordnen und zuordnen, wie hier:

#include <iostream>
#include "cuda_runtime.h"
#include "device_launch_parameters.h"

int main() {
    // Can Host map memory
    cudaSetDeviceFlags(cudaDeviceMapHost);  

    // Allocate memory
    unsigned char *host_src_ptr = NULL;
    cudaHostAlloc(&host_src_ptr, 1024*1024, cudaHostAllocMapped);
    std::cout << "host_src_ptr = " << (size_t)host_src_ptr << std::endl;

    // Get UVA-pointer
    unsigned int *uva_src_ptr = NULL;
    cudaHostGetDevicePointer(&uva_src_ptr, host_src_ptr, 0);
    std::cout << "uva_src_ptr  = " << (size_t)uva_src_ptr << std::endl;

    int b;  std::cin >> b;
    return 0;
}

Wir bekommen gleiche Zeiger in windwos7x64, das bedeutet das cudaHostGetDevicePointer() nichts tun:

HOST_SRC_PTR = 68719476736

UVA_SRC_PTR = 68719476736

Was bedeutet es "ausreichende Mechanismen zum Austausch von MMIO -Regionen zwischen Treibern", welcher Mechanismus hier bedeutet und warum ich Iommu nicht verwenden kann, indem ich die virtuelle Adresse über PCIe in den physischen Bereich der Balk zugreifen kann - ein weiteres Speicher -Mapped -Gerät über PCIe ?

Und bedeutet dies, dass das RDMA GPUDIRECT immer nur physische Adressen (im physischen Adressraum der CPU) betreibt, aber warum wir an die Kernelfunktion senden uva_src_ptr das ist gleich zu host_src_ptr - Einfacher Zeiger im virtuellen Adressraum der CPU?

Answer 1

Das Iommu ist sehr nützlich, als es eine Reihe von Mapping -Registern bietet. Es kann dazu veranlassen, dass jeder physische Speicher innerhalb des von einem Gerät zugänglichen Adressbereichs angezeigt wird, und es kann dazu führen, dass physikalisch verstreute Puffer auch mit Geräten zusammenhängend aussehen. Dies ist nicht gut für PCI/PCI/PCI/PCI-Express-Karten von Drittanbietern oder Remote-Maschinen, die versuchen, auf den rohen physischen Versatz einer NVIDIA-GPU zuzugreifen, da dies zu nicht eigentlich Zugriff auf die beabsichtigten Regionen des Gedächtnisses oder das Hemmung/Einschränken solcher Zugriffe pro Kartenbasis durch die IOMMU-Einheit. Dies muss also deaktiviert werden, weil

"RDMA für gpudirect hängt derzeit auf Alle physischen Adressen sind aus der Sicht der PCI -Geräte gleich."

-nvidia, Konstruktionsüberlegungen für RDMA und GPUDirect

Wenn die Fahrer versuchen, die MMU- und Kartonregionen der CPU und die Kartierung von Speicher zu kartierten E/A (MMIO) für den Gebrauch im Kernelraum zu verwenden, halten sie die zurückgegebene Adresse in der Regel von der Speicherzuordnung für sich selbst. Da jeder Fahrer in seinem eigenen Kontext oder Namespace arbeitet, wechselt der Austausch dieser Zuordnungen zwischen den Treibern von NVIDIA-Treibern und anderen Treibern der Drittanbieter, die RDMA+GPUDIRECT unterstützen möchten, sehr schwierig und würde zu einer Lieferanten-spezifischen Lösung führen (möglicherweise sogar Produkte (möglicherweise sogar Produkte -spezifisch, wenn die Fahrer zwischen den Produkten der 3. Partei stark variieren. Außerdem haben die heutigen Betriebssysteme derzeit keine gute Lösung für den Austausch von MMIO-Zuordnungen zwischen Treibern, weshalb NVIDIA mehrere Funktionen exportiert, die es Drittanbietern ermöglichen, auf diese Informationen aus dem Kernel-Raum selbst problemlos zugreifen zu können.

Nvidia erzwingt die Verwendung von "physischer Adressierung", um über RDMA für gpudirect auf jede Karte zuzugreifen. Dies vereinfacht den Prozess des Verschiebens von Daten von einem Computer in den PCI-Express-Bus eines Remote-Systems durch die Verwendung des physischen Adressierungsschemas dieser Maschine erheblich, ohne sich um Probleme im Zusammenhang mit der virtuellen Adressierung kümmern zu müssen (z. B. virtuelle Adressen auf physische). Jede Karte hat eine physische Adresse, an der sie sich befindet, und kann zu diesem Versatz zugegriffen werden. Der Drittanbieter -Fahrer, der versucht, RDMA -Operationen auszuführen, muss nur ein kleines Stück Logik hinzugefügt werden. Außerdem sind diese 32- oder 64-Bit-Basisadressregister Teil des Standard-PCI-Konfigurationsraums Beim Anbringen an der Karte. Nvidias universelle virtuelle Adressierung (UVA) kümmert sich um die oben genannten physischen Adresszuordnungen zu einem scheinbar übereinstimmenden Speicherbereich für Benutzerraum Anwendungen wie SO:

Diese Speicherregionen sind weiter in drei Typen unterteilt: CPU, GPU und frei, die alle dokumentiert sind hier.

Zurück zu Ihrem Verwendungsfall: Seit Sie dabei sind Benutzerraum, Sie haben keinen direkten Zugriff auf den physischen Adressraum des Systems, und die von Ihnen verwendeten Adressen sind wahrscheinlich virtuelle Adressen, die Ihnen von der UVA von Nvidia zur Verfügung gestellt werden. Unter der Annahme, dass keine früheren Zuordnungen getätigt wurden, sollte Ihre Speicherzuweisung bei Offset +0x00000000 liegen, was dazu führen würde, dass Sie den gleichen Versatz der GPU selbst sehen. Wenn Sie einen zweiten Puffer zuweisen würden, stellen Sie mir vor, Sie würden sehen, dass dieser Puffer unmittelbar nach dem Ende des ersten Puffers startet (bei Offset +0x00100000 von der Basis von der Basis virtuelle Adresse der GPU in Ihrem Fall von 1 MB -Zuweisungen).

Wenn Sie dabei waren Kernelraum, und schrieb jedoch einen Treiber für die Karte Ihres Unternehmens zur Verwendung von RDMA für gpudirect GPU selbst.

Darüber hinaus kann es erwähnenswert sein, dass nicht alle DMA -Motoren virtuelle Adressen für Transfers unterstützen - tatsächlich erfordern die meisten physische Adressen, da die virtuelle Adressierung einer DMA -Engine behandelt wird kann komplex werden (Seite 7), daher fehlt vielen DMA -Motoren die Unterstützung dafür.

Um die Frage aus dem Titel Ihres Beitrags zu beantworten: NVIDIA unterstützt derzeit nur die physische Adressierung für rdma+gpudirect im Kernelraum. Zum Benutzerraum Anwendungen verwenden Sie immer die virtuelle Adresse der GPU, die Ihnen von der UVA von Nvidia gegeben wurde, die sich im virtuellen Adressraum der CPU befindet.

---

In Bezug auf Ihre Anwendung finden Sie hier eine vereinfachte Aufschlüsselung des Prozesses, den Sie für RDMA -Operationen ausführen können:

1. Dein Benutzerraum Die Anwendung erstellt Puffer, die sich im Rahmen des einheitlichen virtuellen Adressraums befinden, den Nvidia bietet (virtuelle Adressen).
2. Anrufen cuPointerGetAttribute(...) P2P -Token erhalten; Diese Token beziehen sich auf das Gedächtnis im Kontext von CUDA.
3. Senden Sie alle diese Informationen an Kernelraum Irgendwie (z. B. IOCTLs, lesen/schreiben an Ihren Treiber usw.). Zumindest möchten Sie, dass diese drei Dinge in Ihrem enden Kernelraum Treiber:
   • P2P -Token (s) zurückgegeben von cuPointerGetAttribute(...)
   • UVA Virtuelle Adresse (eS) des Puffers (en)
   • Größe der Puffer (en)
4. Übersetzen Sie nun diese virtuellen Adressen in ihre entsprechenden physischen Adressen, indem Sie die Kernel-Raum-Funktionen von NVIDIA aufrufen, da diese Adressen in den Seitentabellen von NVIDIA aufgenommen werden und mit der exportierten NVIDIA-NVIDIA zugegriffen werden können, z. B.: nvidia_p2p_get_pages(...), nvidia_p2p_put_pages(...), und nvidia_p2p_free_page_table(...).
5. Verwenden Sie diese physischen Adressen, die im vorherigen Schritt erworben wurden, um Ihre DMA -Engine zu initialisieren, die diese Puffer manipuliert.

Eine eingehendere Erklärung dieses Prozesses kann gefunden werden hier.