Configuración de la administración de energía de NetAdapterCx

  • Artículo

Todos los controladores de cliente netAdapterCx son controladores de Windows Driver Framework (WDF) con funcionalidad de administración de energía similar a todos los controladores WDF. Los controladores netAdapterCx requieren configuraciones de energía adicionales específicas de red, como se detalla en este artículo.

Un dispositivo de red típico admite tres características comunes de administración de energía:

Establecimiento de las funcionalidades de energía del adaptador de red

Después de configurar la funcionalidad de administración de energía de WDF, el siguiente paso es establecer las funcionalidades de energía del adaptador de red. Las funcionalidades de energía se dividen en dos categorías: capacidades de descarga de protocolo de baja energía y funcionalidades de reactivación.

Funcionalidades de descarga de protocolos de baja energía

Para obtener información general sobre cómo usa esta funcionalidad la pila de red de Windows, consulte Descarga de protocolos para la administración de energía NDIS.

Los controladores cliente establecen sus funcionalidades de descarga de protocolo de baja energía llamando a los métodos siguientes adecuados para su hardware:

Funcionalidades de reactivación

Los controladores de cliente llaman a cualquiera de los métodos siguientes para establecer las funcionalidades de reactivación que admite su hardware cuando el dispositivo está en estado de bajo consumo (Dx):

Consumo de energía y reanudación de la latencia

Cuando el dispositivo de red está en Dx, todavía consume energía para realizar la descarga y el brazo para la reactivación. Después de que el dispositivo inicie la reactivación desde Dx, hay un retraso antes de que el dispositivo pueda transferir paquetes de nuevo. Cuanto más profundo sea el estado de energía interno, el dispositivo entra en menos energía que consume mientras está en Dx, pero cuanto más tiempo dure la latencia de reanudación.

En la tabla siguiente se describen las directrices generales relativas al equilibrio entre el consumo de energía y la latencia de reanudación para cada funcionalidad de reactivación.

Importante

Parte de la información está relacionada con el producto de versión preliminar que puede modificarse sustancialmente antes de su publicación comercial. Microsoft no ofrece ninguna garantía, expresa o implícita, con respecto a la información proporcionada. Para obtener más información sobre un tipo de dispositivo específico, consulte la documentación específica de medios y el Programa de compatibilidad de hardware de Windows (WHCP).

Funcionalidad de reactivación Eventos de reactivación Consumo de energía Reanudación de la latencia
PacketFilter Las coincidencias de paquetes configuradas con ReceivePacketFilter Debe ser menor que cuando se encuentra en D0 y el dispositivo debe mantenerse en un estado adecuado para que la latencia de reanudación sea muy pequeña. <= 10 ms
Bitmap Cualquier paquete coincide con el patrón de mapa de bits configurado Debe ser menor que cuando esté armado para PacketFilter porque tiene más latitud en la latencia de reanudación. <= 300 ms
MagicPacket Magic Packet Similar al mapa de bits <= 300 ms
MediaChange Medios conectados o desconectados Similar al mapa de bits <= 300 ms

En el ejemplo siguiente se muestra cómo un controlador cliente podría inicializar sus capacidades de energía. Lo hace al iniciar el adaptador net, pero antes de llamar a NetAdapterStart. En este ejemplo, el controlador cliente establece sus funcionalidades de reactivación de mapa de bits, cambio multimedia y filtro de paquetes.

//
// Set bitmap wake capabilities
//
NET_ADAPTER_WAKE_BITMAP_CAPABILITIES bitmapCapabilities;
NET_ADAPTER_WAKE_BITMAP_CAPABILITIES_INIT(&bitmapCapabilities);

bitmapCapabilities.BitmapPattern = TRUE;
bitmapCapabilities.MaximumPatternCount = deviceContext->PowerFiltersSupported;
bitmapCapabilities.MaximumPatternSize = 256;

NetAdapterWakeSetBitmapCapabilities(Adapter, &bitmapCapabilities);

//
// Set media change wake capabilities
//
NET_ADAPTER_WAKE_MEDIA_CHANGE_CAPABILITIES mediaChangeCapabilities;
NET_ADAPTER_WAKE_MEDIA_CHANGE_CAPABILITIES_INIT(&mediaChangeCapabilities);

mediaChangeCapabilities.MediaConnect = TRUE;
mediaChangeCapabilities.MediaDisconnect = TRUE;

NetAdapterWakeSetMediaChangeCapabilities(Adapter, &mediaChangeCapabilities);

//
// Set packet filter wake capabilities
//
if(deviceContext->SelectiveSuspendSupported)
{
    NET_ADAPTER_WAKE_PACKET_FILTER_CAPABILITIES packetFilterCapabilities;
    NET_ADAPTER_WAKE_PACKET_FILTER_CAPABILITIES_INIT(&packetFilterCapabilities);

    packetFilterCapabilities.PacketFilterMatch = TRUE;

    NetAdapterWakeSetPacketFilterCapabilities(Adapter, &packetFilterCapabilities);
}

Opcionalmente, el cliente puede registrar EVT_NET_DEVICE_PREVIEW_POWER_OFFLOAD y EVT_NET_DEVICE_PREVIEW_WAKE_SOURCE funciones de devolución de llamada para aceptar o rechazar las descargas de protocolo entrantes y los patrones de reactivación.

Patrones de descarga y reactivación del protocolo de programación

Durante la secuencia de apagado del dispositivo, el controlador recorre en iteración los patrones de reactivación habilitados y las descargas de energía del protocolo y los programa en el hardware. El controlador lo hace en sus funciones de devolución de llamada EvtDeviceArmWakeFromS0 y EvtDeviceArmWakeFromSx .

En el ejemplo siguiente se muestra cómo un controlador cliente puede iterar en la lista de patrones de reactivación para comprobar si hay una activación en la entrada de paquete mágico y, a continuación, iterar por la lista de descarga de energía para procesar la descarga del protocolo ARP IPv4:

NTSTATUS
EvtDeviceArmWakeFromSx(
    WDFDEVICE     Device
)
{
    NETADAPTER adapter = GetDeviceContext(Device)->Adapter;

    //
    // Process wake source list
    //
    NET_WAKE_SOURCE_LIST wakeSourceList;
    NET_WAKE_SOURCE_LIST_INIT(&wakeSourceList);

    NetDeviceGetWakeSourceList(Device, &wakeSourceList);

    for(UINT32 i = 0; i < NetWakeSourceListGetCount(&wakeSourceList; i++); i++)
    {
        NETWAKESOURCE wakeSource = NetWakeSourceListGetElement(&wakeSourceList, i);
        NET_WAKE_SOURCE_TYPE const wakeSourceType = NetWakeSourceGetType(wakeSource);

        if(wakeSourceType == NetWakeSourceTypeMagicPacket)
        {
            // Enable magic packet wake for the adapter
            ..
            //
        }
    }

    //
    // Process power offload list
    //
    NET_POWER_OFFLOAD_LIST powerOffloadList;
    NET_POWER_OFFLOAD_LIST_INIT(&powerOffloadList);

    NetDeviceGetPowerOffloadList(Device, &powerOffloadList);

    for(UINT32 i = 0; i < NetPowerOffloadListGetCount(&powerOffloadList); i++)
    {
        NETPOWEROFFLOAD powerOffload = NetPowerOffloadGetElement(&powerOffloadList, i);
        NET_POWER_OFFLOAD_TYPE const powerOffloadType = NetPowerOffloadGetType(powerOffload);

        if(powerOffloadType == NetPowerOffloadTypeArp)
        {
            // Enable ARP protocol offload for the adapter
            ..
            //
        }
    }

    return STATUS_SUCCESS;
}

En la vuelta a alta potencia , el conductor normalmente deshabilita las descargas de energía y los patrones de reactivación del protocolo programados anteriormente en las devoluciones de llamada EvtDeviceDisarmWakeFromSx y EvtDeviceDisarmWakeFromS0 correspondientes.

Motivo de reactivación de informes

Importante

Es obligatorio que los controladores cliente notifiquen el motivo de reactivación a NetAdapterCx.

Cuando el hardware de la NIC reactiva el sistema, el controlador de cliente debe informar a NetAdapterCx que el origen de reactivación desencadenó la reactivación. Para la mayoría de los orígenes de reactivación, los controladores usan la estructura NET_ADAPTER_WAKE_REASON_PACKET para describir el paquete de red que desencadenó la reactivación.

Si el NET_WAKE_SOURCE_TYPE es:

Escenarios de administración de energía para el sistema modern standby

Importante

Para la plataforma moderna en espera, el controlador de dispositivo de red debe:

Consulte la documentación específica de medios y WHCP para conocer los requisitos de espera modernos completos para el tipo de dispositivo.

El sistema operativo es responsable de las decisiones de directiva de energía del dispositivo de red. Por ejemplo, el sistema operativo controla cuándo un dispositivo debe ir a Dx y qué tipos de eventos de red debe reactivar el dispositivo. La responsabilidad del controlador del dispositivo es ejecutar de forma confiable la secuencia de transición de energía cuando lo solicite el sistema operativo y, a continuación, programar correctamente su hardware para la condición de reactivación establecida por el sistema operativo.

El sistema operativo toma decisiones de directiva de energía basadas en un amplio conjunto de factores, incluidas las directivas de energía y las opciones de usuario de todo el sistema. A continuación se muestran algunas directivas de energía comunes que se usan para los dispositivos de red en un sistema modern standby:

Importante

Estas directivas de energía pueden cambiar con las actualizaciones del sistema operativo y se proporciona la siguiente información como ejemplo. Se deben evitar dependencias en el comportamiento de un extremo a otro específico del sistema operativo.

  • Cuando la pantalla del EQUIPO está activada y el dispositivo de red ha estado idling, el sistema operativo pide al dispositivo que vaya a Dx y lo amese para packetFilter y reactivación mediaChange.

  • Cuando el equipo entra en espera moderna y el dispositivo de red ha estado desplazándose, el sistema operativo pide a la NIC ir a Dx y armarlo para mapa de bits, MediaChange y activación de paquete mágico.

  • Cuando el PC va a Hibernación, el sistema operativo pide a la NIC que vaya a Dx y lo ameste para la reactivación de paquete mágico.

Nota: Los controladores de cliente de NetAdapterCx controlan la visibilidad de la pestaña administración de energía. Para obtener más información, consulte Control de usuario del comportamiento inactivo y de reactivación del dispositivo.