estructura de NDK_ADAPTER_INFO (ndkinfo.h)
La estructura NDK_ADAPTER_INFO especifica información sobre los límites y funcionalidades de un adaptador NDK.
Sintaxis
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
Las versiones principales y secundarias de la interfaz NDK (NDK_VERSION).
VendorId
Identificador único organizativo (OUI) de un proveedor.
DeviceId
Identificador de dispositivo definido por el proveedor.
MaxRegistrationSize
Tamaño máximo, en bytes, de un único registro de memoria al que puede dirigirse el adaptador.
MaxWindowSize
Tamaño máximo, en bytes, para una sola ventana de memoria.
FRMRPageCount
Tamaño de región de memoria de registro rápido (FRMR) (en PAGE_SIZE páginas) para el que el adaptador admite el mayor número de FRMR. Un proveedor debe admitir al menos 16 páginas FRMR. Normalmente, este valor lo usan las capas superiores como un tamaño FRMR que optimiza las operaciones simultáneas de E/S basadas en FRMR. Por lo tanto, la publicidad de un valor mayor que 16 solo debe realizarse si el número total de FRMR admitidos con ese tamaño no se reduce significativamente como resultado.
MaxInitiatorRequestSge
Número máximo de entradas de recopilación de dispersión (SGE) que se pueden especificar en una sola solicitud a través de una cola de iniciador.
MaxReceiveRequestSge
Número máximo de SGE que se pueden especificar en una sola solicitud a través de una cola de recepción.
MaxReadRequestSge
Número máximo de SGE que se pueden especificar en una solicitud de lectura.
MaxTransferLength
Longitud total máxima a la que pueden hacer referencia todos los SGE en una única solicitud de envío, recepción, lectura o escritura.
MaxInlineDataSize
Cantidad máxima de datos insertados, en bytes, que se pueden enviar en una única solicitud de envío o escritura.
MaxInboundReadLimit
Número máximo de operaciones de lectura entrantes en curso para cada QP.
MaxOutboundReadLimit
Número máximo de operaciones de lectura salientes en curso para cada QP.
MaxReceiveQueueDepth
Número máximo de solicitudes pendientes para cada cola de recepción.
MaxInitiatorQueueDepth
Número máximo de solicitudes pendientes para cada cola del iniciador.
MaxSrqDepth
Número máximo de solicitudes pendientes para cada cola de recepción compartida (SRQ). Un valor de cero significa que no hay compatibilidad con SRQ.
MaxCqDepth
Número máximo de entradas de finalización para cada cola de finalización (CQ).
LargeRequestThreshold
La sugerencia de tamaño de datos, en bytes, por encima de las cuales las operaciones de lectura y escritura producirán mejores resultados que las operaciones de envío y recepción.
MaxCallerData
Tamaño máximo, en bytes, de los datos privados que se pueden enviar con una solicitud de conexión.
MaxCalleeData
Tamaño máximo, en bytes, de los datos privados que se pueden enviar con una solicitud de aceptación o rechazo.
AdapterFlags
Conjunto de marcas que determinan las propiedades del adaptador. Las marcas definidas actualmente incluyen:
| Valor | Significado |
|---|---|
|
Establezca si el proveedor escribe datos entrantes en el búfer del consumidor en orden. Es decir, se garantiza que la última posición de byte del búfer del consumidor no se actualice antes de cualquier posición de byte anterior. |
|
Establezca si el proveedor no requiere derechos de acceso especiales en el búfer receptor para una solicitud de lectura de RDMA. Cuando se establece esta marca, no es necesario que el consumidor use las marcas de NDK_MR_FLAG_RDMA_READ_SINK o NDK_OP_FLAG_RDMA_READ_SINK cuando registra búferes receptores para las solicitudes de lectura de RDMA. El consumidor también puede usar asignaciones de direcciones lógicas directamente (con un token obtenido con la función NDK_FN_GET_PRIVILEGED_MEMORY_REGION_TOKEN ) como búferes receptores de lectura rdma. Esto es similar al acceso a los búferes locales para las operaciones de escritura, envío y recepción de RDMA. |
|
Establezca si el proveedor admite la moderación de interrupción controlada mediante programación para cada cola de finalización (CQ). Cuando se establece esta marca, un consumidor de NDK puede usar la función NDK_FN_CONTROL_CQ_INTERRUPT_MODERATION en la tabla NDK_CQ_DISPATCH . |
|
Establezca si el proveedor admite el procesamiento simultáneo de varias conexiones con varios motores de ejecución. Si se establece esta marca, un consumidor de NDK que usa más de una conexión simultáneamente en el adaptador podría proporcionar un mejor rendimiento que una sola conexión. |
|
Establezca si el proveedor admite la invalidación del token local especificado en el primer NDK_SGE pasado a una función NdkRead (NDK_FN_READ) al completar la solicitud de lectura.
Nota Este valor solo se admite en NDKPI 1.2 (Windows Server 2012 R2) y versiones posteriores. |
|
Establezca si el proveedor admite el cambio de tamaño de los objetos CQ. Si no se establece esta marca, el consumidor no debe intentar cambiar el tamaño de un CQ. |
|
Establezca si el proveedor admite conexiones de bucle invertido. Es decir, bucle invertido desde una dirección de red local en una RNIC determinada a la misma dirección local en la misma RNIC. |
RdmaTechnology
Comentarios
La función NDK_FN_QUERY_ADAPTER_INFO recupera el NDK_ADAPTER_INFO, que contiene información sobre varios límites y funcionalidades del adaptador.
Requisitos
| Cliente mínimo compatible | Ninguno compatible, compatible con NDIS 6.30 y versiones posteriores. |
| Servidor mínimo compatible | Windows Server 2012 |
| Encabezado | ndkinfo.h (incluya Ndkpi.h) |
Consulte también
NDK_FN_CONTROL_CQ_INTERRUPT_MODERATION
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de