Partilhar via


Configurando o gerenciamento de energia NetAdapterCx

Todos os drivers de cliente NetAdapterCx são drivers do Windows Driver Framework (WDF) com funcionalidade de gerenciamento de energia semelhante a todos os drivers WDF. Os drivers NetAdapterCx exigem configurações de energia adicionais específicas da rede, conforme detalhado neste artigo.

Um dispositivo de rede típico suporta três recursos comuns de gerenciamento de energia:

  • O dispositivo de rede pode entrar em um estado de baixa potência (Dx) quando instruído pelo sistema operacional.

  • Quando o dispositivo de rede está no estado Dx, pode enviar um sinal de ativação se uma condição de ativação pré-configurada tiver ocorrido.

  • Quando o dispositivo de rede está no estado Dx, ele ainda pode responder a algumas solicitações de rede comumente usadas para manter a presença do sistema host na rede sem ativar o sistema host. Consulte Definindo recursos de energia do adaptador de rede.

Definindo os recursos de energia do adaptador de rede

Depois de configurar a funcionalidade de gerenciamento de energia WDF, a próxima etapa é definir os recursos de energia do adaptador de rede. As capacidades de energia são divididas em duas categorias: Capacidades de descarga de protocolo de baixa potência e Capacidades de despertar.

Capacidades de descarga de protocolo de baixa potência

Para obter informações básicas sobre como a pilha de rede do Windows usa esse recurso, consulte Protocol Offloads for NDIS Power Management.

Os drivers de cliente definem as suas capacidades de descarregamento de protocolos de baixa potência chamando os seguintes métodos apropriados para o seu hardware:

Capacidades de despertar

Os controladores de cliente chamam qualquer um dos seguintes métodos para definir as capacidades de ativação que o seu hardware suporta quando o dispositivo está em estado de baixa energia (Dx):

Consumo de energia e latência de retomada

Quando o dispositivo de rede está em Dx, ele ainda consome energia para realizar a descarga de tarefas e preparar para acordar. Depois que o dispositivo sai do estado Dx, há um atraso antes que o dispositivo possa voltar a transferir pacotes. Quanto mais profundo for o estado de energia interna, menos energia consome enquanto estiver em Dx, mas maior será a latência de retomada.

A tabela a seguir descreve as diretrizes gerais sobre a compensação entre o consumo de energia e a latência de retoma para cada capacidade de despertar.

Importante

Algumas informações referem-se a produtos pré-lançados que podem ser substancialmente modificados antes do lançamento comercial. A Microsoft não oferece garantias, expressas ou implícitas, em relação às informações fornecidas. Para obter mais informações sobre um tipo de dispositivo específico, consulte a documentação específica de mídia e o Windows Hardware Compatibility Program (WHCP).

Capacidade de despertar Eventos de Despertar Consumo de energia Latência de retomada
PacketFilter Qualquer pacote que corresponda ao filtro de pacotes recibidos configurado Deve ser menor do que quando em D0, e o dispositivo precisa ser mantido em um estado apropriado para que a latência de retomada seja muito pequena <= 10 ms
Bitmap Qualquer pacote corresponde ao padrão de bitmap configurado Deve ser menor do que quando configurado para PacketFilter porque tem mais latitude na latência de retoma. <= 300 ms
MagicPacket Pacote mágico Semelhantes a Bitmap <= 300 ms
MediaChange Mídia conectada ou desconectada Semelhantes a Bitmap <= 300 ms

O exemplo a seguir ilustra como um driver de cliente pode inicializar seus recursos de energia. Ele faz isso ao iniciar o adaptador de rede, mas antes de chamar NetAdapterStart. Neste exemplo, o driver do cliente define seus recursos de bitmap, alteração de mídia e ativação do filtro de pacotes.

//
// 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);
}

O cliente pode, opcionalmente, registrar EVT_NET_DEVICE_PREVIEW_POWER_OFFLOAD e EVT_NET_DEVICE_PREVIEW_WAKE_SOURCE funções de retorno de chamada para aceitar ou rejeitar descarregamentos de protocolo de entrada e padrões de despertar.

Padrões de descarga de energia e despertar do protocolo de programação

Durante a sequência de desligamento do dispositivo, o driver itera pelos padrões de ativação e transferências de energia do protocolo e programa-os no hardware. O driver faz isso nas suas funções de retorno de chamada EvtDeviceArmWakeFromS0 e EvtDeviceArmWakeFromSx.

O exemplo a seguir mostra como um driver de cliente pode iterar sobre a lista de padrões de ativação para verificar uma entrada de ativação por pacote mágico e, em seguida, iterar sobre a lista de descarregamento de energia para processar o descarregamento do 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++)
    {
        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 = NetPowerOffloadListGetElement(&powerOffloadList, i);
        NET_POWER_OFFLOAD_TYPE const powerOffloadType = NetPowerOffloadGetType(powerOffload);

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

    return STATUS_SUCCESS;
}

No caminho de volta para alta potência , o motorista normalmente desativa as descargas de energia do protocolo previamente programadas e os padrões de despertar nos retornos de chamada correspondentes EvtDeviceDisarmWakeFromSx e EvtDeviceDisarmWakeFromS0. NetDeviceGetPowerOffloadList e NetDeviceGetWakeSourceList podem ser usados para recuperar os descarregamentos de energia do protocolo e o padrão de despertar nos retornos de chamada.

Relatar o motivo do despertar

Importante

É obrigatório que os drivers de cliente relatem o motivo de despertar para NetAdapterCx.

Quando o hardware da NIC desperta o sistema, o driver do cliente deve relatar ao NetAdapterCx qual fonte de ativação desencadeou a ativação. Para a maioria das fontes de ativação, os controladores utilizam a estrutura NET_ADAPTER_WAKE_REASON_PACKET para descrever o pacote de rede que disparou a ativação.

Se o NET_WAKE_SOURCE_TYPE é:

Cenários de gerenciamento de energia para o sistema Modern Standby

Importante

Para a plataforma Modern Standby, o controlador do dispositivo de rede deve:

Consulte a documentação específica da mídia e o WHCP para obter os requisitos completos do Modo de Espera Moderno para o seu tipo de dispositivo.

O SO é responsável pelas decisões de política de energia do dispositivo de rede. Por exemplo, o sistema operativo controla quando um dispositivo deve ir para Dx e quais tipos de eventos de rede devem despertar o dispositivo. A responsabilidade do driver de dispositivo é executar de forma confiável a sequência de transição de energia quando solicitado pelo sistema operacional e, em seguida, programar corretamente seu hardware para a condição de despertar definida pelo sistema operacional.

O sistema operacional toma decisões de política de energia com base em um amplo conjunto de fatores, incluindo políticas de energia em todo o sistema e escolhas do usuário. A seguir estão algumas políticas de energia comuns usadas para dispositivos de rede em um sistema Modern Standby:

Importante

Essas políticas de energia podem mudar com as atualizações do sistema operacional e as informações a seguir são fornecidas como exemplo. Dependências em comportamentos específicos de ponta a ponta do sistema operacional devem ser evitadas.

  • Quando a tela do PC está ligada e o dispositivo de rede está inativo, o sistema operacional pede que o dispositivo vá para Dx e o arma para PacketFilter e MediaChange wake.

  • Quando o PC entra no modo Modern Standby e o dispositivo de rede está inativo, o SO solicita ao controlador de interface de rede (NIC) que transite para o estado Dx e o prepara para acordar com Bitmap, MediaChange e Magic Packet.

  • Quando o PC entra em hibernação, o SO pede à NIC para entrar em Dx e prepara-a para acordar com um "Magic Packet".

Nota: Os drivers de cliente NetAdapterCx controlam a visibilidade da guia de gerenciamento de energia. Para obter mais informações, consulte User Control of Device Idle and Wake Behavior.