Configurando o gerenciamento de energia do NetAdapterCx
Todos os drivers de cliente NetAdapterCx são drivers do WDF (Windows Driver Framework) com funcionalidade de gerenciamento de energia semelhante a todos os drivers do WDF. Os drivers NetAdapterCx exigem configurações adicionais de energia específicas da rede, conforme detalhado neste artigo.
Um dispositivo de rede típico dá suporte a três recursos comuns de gerenciamento de energia:
O dispositivo de rede pode inserir um estado Dx (menor potência) quando instruído pelo sistema operacional.
O driver do cliente registra retornos de chamada de eventos opcionais do WDF para receber notificação de transições de energia, conforme descrito em Suporte ao PnP e ao Gerenciamento de Energia em Drivers de Função.
Se o dispositivo de rede puder inserir seu estado Dx enquanto o sistema permanecer em seu estado de trabalho (S0), o driver do cliente deverá dar suporte à desligar ociosa. Consulte Suporte à ociosidade de energia para baixo. Além do controle de usuário padrão do comportamento ocioso e de ativação do dispositivo disponível para todos os dispositivos WDF, o NetAdapterCx permite controle ocioso específico de rede adicional por meio de *IdleRestriction , conforme definido em Palavras-chave INF Padronizadas para Gerenciamento de Energia.
Quando o dispositivo de rede está no estado Dx, ele pode disparar um sinal de ativação se uma condição de ativação pré-configurada tiver ocorrido.
Para obter detalhes sobre como um dispositivo WDF pode ativar o sistema de um estado de baixa energia em todo o sistema, consulte Suporte ao wake-up do sistema.
O NetAdapterCx fornece APIs para o driver cliente declarar para quais eventos de rede seu hardware tem suporte de ativação. Consulte Configurando recursos de energia do adaptador de rede.
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 acordar o sistema host. Consulte Configurando recursos de energia do adaptador de rede.
Definindo recursos de energia do adaptador de rede
Depois de configurar a funcionalidade de gerenciamento de energia do WDF, a próxima etapa é definir os recursos de energia do adaptador de rede. Os recursos de energia são divididos em duas categorias: funcionalidades de descarregamento de protocolo de baixa potência e Recursos de ativação.
Funcionalidades de descarregamento de protocolo de baixa potência
Para obter informações em segundo plano sobre como a pilha de rede do Windows usa essa funcionalidade, consulte Descarregamentos de protocolo para gerenciamento de energia do NDIS.
Os drivers de cliente definem seus recursos de descarregamento de protocolo de baixa energia chamando os seguintes métodos apropriados para seu hardware:
Ativar recursos
Os drivers de cliente chamam qualquer um dos seguintes métodos para definir os recursos de ativação compatíveis com o hardware quando o dispositivo está em estado de baixa potência (Dx):
- NetAdapterWakeSetBitmapCapabilities
- NetAdapterWakeSetMagicPacketCapabilities
- NetAdapterWakeSetMediaChangeCapabilities
- NetAdapterWakeSetPacketFilterCapabilities
Consumo de energia e latência de retomada
Quando o dispositivo de rede está em Dx, ele ainda consome energia para executar descarregamento e arm para ativação. Depois que o dispositivo inicia a ativação do Dx, há um atraso antes que o dispositivo possa transferir pacotes novamente. Quanto mais profundo o estado de energia interno, o dispositivo entra em menos energia que consome enquanto está no Dx, mas quanto maior 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 retomada para cada funcionalidade de ativação.
Importante
Algumas informações referem-se ao produto pré-relacionado que pode ser substancialmente modificado 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 da mídia e o WHCP (Programa de Compatibilidade de Hardware do Windows).
Funcionalidade de ativação | Eventos de ativação | Consumo de Energia | Retomar Latência |
---|---|---|---|
PacketFilter | Qualquer pacote corresponde ao ReceivePacketFilter configurado | Deve ser menor do que quando estiver 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 armado para PacketFilter porque ele tem mais latitude na latência de retomada | <= 300 ms |
MagicPacket | Pacote Magic | Semelhante ao Bitmap | <= 300 ms |
MediaChange | Mídia conectada ou desconectada | Semelhante ao 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 de filtro de pacote.
//
// 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, o cliente pode 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 ativação.
Padrões de descarregamento e ativação de protocolo de programação
Durante a sequência de desligar o dispositivo, o driver itera por meio dos padrões de ativação habilitados e descarrega a energia do protocolo e os programa no hardware. O driver faz isso em 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 marcar para uma ativação na entrada de pacote mágico e, em seguida, iterar sobre a lista de descarregamento de energia para processar o descarregamento de 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;
}
No caminho de volta à alta potência, o driver normalmente desabilita os descarregamentos de energia de protocolo programados anteriormente e os padrões de ativação nos retornos de chamada EvtDeviceDisarmWakeFromS0 correspondentes.
Motivo da ativação do relatório
Importante
É obrigatório que os drivers de cliente relatem o motivo da ativação para NetAdapterCx.
Quando o hardware nic ativa o sistema, o driver do cliente deve relatar ao NetAdapterCx qual fonte de ativação disparou a ativação. Para a maioria das fontes de ativação, os drivers usam a estrutura NET_ADAPTER_WAKE_REASON_PACKET para descrever o pacote de rede que disparou a ativação.
Se o NET_WAKE_SOURCE_TYPE for:
NetWakeSourceTypeBitmapPattern, chame NET_ADAPTER_WAKE_REASON_PACKET_INIT para inicializar a estrutura de NET_ADAPTER_WAKE_REASON_PACKET . Chame NetAdapterReportWakeReasonPacket para relatar esse motivo de ativação.
NetWakeSourceTypeMagicPacket, chame NET_ADAPTER_WAKE_REASON_MAGIC_PACKET_INIT para inicializar a estrutura de NET_ADAPTER_WAKE_REASON_PACKET . Chame NetAdapterReportWakeReasonPacket para relatar esse motivo de ativação.
NetWakeSourceTypePacketFilterMatch, chame NET_ADAPTER_WAKE_REASON_FILTER_PACKET_INIT para inicializar a estrutura NET_ADAPTER_WAKE_REASON_PACKET . Chame NetAdapterReportWakeReasonPacket para relatar esse motivo de ativação.
NetWakeSourceTypeMediaChange, chame NetAdapterReportWakeReasonMediaChange para relatar esse motivo de ativação.
Cenários de gerenciamento de energia para o sistema de espera moderno
Importante
Para a plataforma de Espera Moderna, o driver de dispositivo de rede deve:
- Chame WdfDeviceInitSetPnpPowerEventCallbacks para registrar retornos de chamada de energia.
- Chame WdfDeviceAssignS0IdleSettings para dar suporte à idling do dispositivo quando o sistema estiver em seu estado de trabalho (S0).
- Chame WdfDeviceInitSetPowerPolicyEventCallbacks para registrar retornos de chamada de ativação.
- Suporte a recursos de descarregamento de protocolo de baixa energia apropriados para o tipo de dispositivo.
- Suporte a recursos de ativação apropriados para o tipo de dispositivo.
Consulte a documentação específica da mídia e o WHCP para obter os requisitos completos de Espera Moderna para o tipo de dispositivo.
O sistema operacional é responsável pelas decisões de política de energia do dispositivo de rede. Por exemplo, o sistema operacional controla quando um dispositivo deve ir para dx e quais tipos de eventos de rede o dispositivo deve ativar. A responsabilidade do driver do 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 ativação 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. Veja a seguir algumas políticas de energia comuns usadas para dispositivos de rede em um sistema de espera moderno:
Importante
Essas políticas de energia podem ser alteradas com atualizações do sistema operacional e as informações a seguir são fornecidas como exemplo. As dependências do comportamento de ponta a ponta específica do sistema operacional devem ser evitadas.
Quando a tela do computador está ativada e o dispositivo de rede está em idling, o sistema operacional solicita que o dispositivo vá para dx e arma-o para a ativação packetFilter e MediaChange.
Quando o computador entra em Modo de Espera Moderno e o dispositivo de rede está em idling, o sistema operacional solicita que a NIC vá para Dx e armague-o para a ativação de Bitmap, MediaChange e Magic Packet.
Quando o computador vai para Hibernação, o sistema operacional solicita que a NIC vá para dx e arma-o para a ativação do Pacote Mágico.
Observação: os drivers de cliente NetAdapterCx controlam a visibilidade da guia de gerenciamento de energia. Para obter mais informações, consulte Controle de usuário do dispositivo ocioso e comportamento de ativação.