NDK_ADAPTER_INFO-Struktur (ndkinfo.h)
Die NDK_ADAPTER_INFO-Struktur gibt Informationen zu Grenzwerten und Funktionen eines NDK-Adapters an.
Syntax
typedef struct _NDK_ADAPTER_INFO {
NDK_VERSION Version;
UINT32 VendorId;
UINT32 DeviceId;
SIZE_T MaxRegistrationSize;
SIZE_T MaxWindowSize;
ULONG FRMRPageCount;
ULONG MaxInitiatorRequestSge;
ULONG MaxReceiveRequestSge;
ULONG MaxReadRequestSge;
ULONG MaxTransferLength;
ULONG MaxInlineDataSize;
ULONG MaxInboundReadLimit;
ULONG MaxOutboundReadLimit;
ULONG MaxReceiveQueueDepth;
ULONG MaxInitiatorQueueDepth;
ULONG MaxSrqDepth;
ULONG MaxCqDepth;
ULONG LargeRequestThreshold;
ULONG MaxCallerData;
ULONG MaxCalleeData;
ULONG AdapterFlags;
NDK_RDMA_TECHNOLOGY RdmaTechnology;
} NDK_ADAPTER_INFO;
Members
Version
Die Haupt- und Nebenversionen der NDK-Schnittstelle (NDK_VERSION).
VendorId
Der eindeutige Organisationsbezeichner (OUI) eines Anbieters.
DeviceId
Ein vom Hersteller definierter Gerätebezeichner.
MaxRegistrationSize
Die maximale Größe einer einzelnen Speicherregistrierung in Bytes, die der Adapter adressieren kann.
MaxWindowSize
Die maximale Größe in Bytes für ein einzelnes Speicherfenster.
FRMRPageCount
Die FrMR-Größe (Fast Register Memory Region) (in PAGE_SIZE Seiten), für die der Adapter die größte Anzahl von FRMRs unterstützt. Ein Anbieter muss mindestens 16 FRMR-Seiten unterstützen. Dieser Wert wird in der Regel von oberen Ebenen als FRMR-Größe verwendet, die gleichzeitige FRMR-basierte E/A-Vorgänge optimiert. Daher sollte die Werbung für einen Wert größer als 16 nur erfolgen, wenn die Gesamtzahl der mit dieser Größe unterstützten FRMRs nicht sinnvoll verringert wird.
MaxInitiatorRequestSge
Die maximale Anzahl von Scatter-Gather-Einträgen (SGEs), die in einer einzelnen Anforderung über eine Initiatorwarteschlange angegeben werden kann.
MaxReceiveRequestSge
Die maximale Anzahl von SGEs, die in einer einzelnen Anforderung über eine Empfangswarteschlange angegeben werden kann.
MaxReadRequestSge
Die maximale Anzahl von SGEs, die in einer Leseanforderung angegeben werden kann.
MaxTransferLength
Die maximale Gesamtlänge, auf die alle SGEs in einer einzelnen Sende-, Empfangs-, Lese- oder Schreibanforderung verweisen können.
MaxInlineDataSize
Die maximale Menge an Inlinedaten in Bytes, die in einer einzelnen Sende- oder Schreibanforderung gesendet werden kann.
MaxInboundReadLimit
Die maximale Anzahl von eingehenden Lesevorgängen für jeden QP.
MaxOutboundReadLimit
Die maximale Anzahl von laufenden ausgehenden Lesevorgängen für jeden QP.
MaxReceiveQueueDepth
Die maximale Anzahl ausstehender Anforderungen für jede Empfangswarteschlange.
MaxInitiatorQueueDepth
Die maximale Anzahl ausstehender Anforderungen für jede Initiatorwarteschlange.
MaxSrqDepth
Die maximale Anzahl ausstehender Anforderungen für jede freigegebene Empfangswarteschlange (SRQ). Ein Wert von null bedeutet keine SRQ-Unterstützung.
MaxCqDepth
Die maximale Anzahl von Vervollständigungseinträgen für jede Vervollständigungswarteschlange (CQ).
LargeRequestThreshold
Der Datengrößehinweis in Bytes, ab dem Lese- und Schreibvorgänge bessere Ergebnisse liefern als Sende- und Empfangsvorgänge.
MaxCallerData
Die maximale Größe der privaten Daten in Bytes, die mit einer Verbindungsanforderung gesendet werden können.
MaxCalleeData
Die maximale Größe der privaten Daten in Bytes, die mit einer Annahme- oder Ablehnungsanforderung gesendet werden können.
AdapterFlags
Eine Reihe von Flags, die die Adaptereigenschaften bestimmen. Zu den derzeit definierten Flags gehören:
| Wert | Bedeutung |
|---|---|
|
Legen Sie fest, ob der Anbieter eingehende Daten in die Reihenfolge in den Puffer des Consumer schreibt. Das heißt, die letzte Byteposition im Puffer des Consumers wird garantiert nicht vor einer vorherigen Byteposition aktualisiert. |
|
Legen Sie fest, ob der Anbieter keine speziellen Zugriffsrechte für den Senkenpuffer für eine RDMA-Leseanforderung benötigt. Wenn dieses Flag festgelegt ist, muss der Consumer nicht die NDK_MR_FLAG_RDMA_READ_SINK- oder NDK_OP_FLAG_RDMA_READ_SINK-Flags verwenden, wenn er Senkenpuffer für RDMA-Leseanforderungen registriert. Der Consumer kann auch logische Adresszuordnungen direkt (mit einem Token, das mit der NDK_FN_GET_PRIVILEGED_MEMORY_REGION_TOKEN-Funktion abgerufen wird) als RDMA-Lesesenkenpuffer verwenden. Dies ähnelt dem Zugriff auf lokale Puffer für RDMA-Schreib-, Sende- und Empfangsvorgänge. |
|
Legen Sie fest, ob der Anbieter programmgesteuert gesteuerte Interruptmoderation für jede Vervollständigungswarteschlange (CQ) unterstützt. Wenn dieses Flag festgelegt ist, kann ein NDK-Consumer die NDK_FN_CONTROL_CQ_INTERRUPT_MODERATION-Funktion in der NDK_CQ_DISPATCH Tabelle verwenden. |
|
Legen Sie fest, ob der Anbieter die gleichzeitige Verarbeitung mehrerer Verbindungen mit mehreren Ausführungs-Engines unterstützt. Wenn dieses Flag festgelegt ist, bietet ein NDK-Consumer, der mehrere Verbindungen gleichzeitig für den Adapter verwendet, möglicherweise eine bessere Leistung als eine einzelne Verbindung. |
|
Legen Sie fest, ob der Anbieter die Ungültigkeit des lokalen Tokens unterstützt, das im ersten NDK_SGE beim Abschluss der Leseanforderung an eine NdkRead-Funktion (NDK_FN_READ) übergeben wird.
Hinweis Dieser Wert wird nur in NDKPI 1.2 (Windows Server 2012 R2) und höher unterstützt. |
|
Legen Sie fest, ob der Anbieter die Größenänderung von CQ-Objekten unterstützt. Wenn dieses Flag nicht festgelegt ist, darf der Consumer keine CQ-Größe ändern. |
|
Legen Sie fest, ob der Anbieter Loopbackverbindungen unterstützt. Das heißt, ein Loopback von einer lokalen Netzwerkadresse auf einer bestimmten RNIC an dieselbe lokale Adresse auf derselben RNIC. |
RdmaTechnology
Hinweise
Die NDK_FN_QUERY_ADAPTER_INFO-Funktion ruft die NDK_ADAPTER_INFO ab, die Informationen zu verschiedenen Grenzwerten und Funktionen des Adapters enthält.
Anforderungen
| Unterstützte Mindestversion (Client) | Keine unterstützt, wird in NDIS 6.30 und höher unterstützt. |
| Unterstützte Mindestversion (Server) | Windows Server 2012 |
| Kopfzeile | ndkinfo.h (include Ndkpi.h) |
Weitere Informationen
NDK_FN_CONTROL_CQ_INTERRUPT_MODERATION
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für