Configuration de la gestion de l’alimentation NetAdapterCx

  • Article

Tous les pilotes clients NetAdapterCx sont des pilotes Windows Driver Framework (WDF) avec des fonctionnalités de gestion de l’alimentation similaires à tous les pilotes WDF. Les pilotes NetAdapterCx nécessitent des configurations d’alimentation supplémentaires spécifiques au réseau, comme indiqué dans cet article.

Un appareil réseau classique prend en charge trois fonctionnalités courantes de gestion de l’alimentation :

Définition des fonctionnalités d’alimentation de la carte réseau

Après avoir configuré la fonctionnalité de gestion de l’alimentation WDF, l’étape suivante consiste à définir les fonctionnalités d’alimentation de la carte réseau. Les fonctionnalités d’alimentation sont divisées en deux catégories : les fonctionnalités de déchargement du protocole à faible puissance et les fonctionnalités de mise en éveil.

Fonctionnalités de déchargement du protocole à faible consommation d’énergie

Pour obtenir des informations générales sur la façon dont la pile réseau Windows utilise cette fonctionnalité, consultez Déchargements de protocole pour la gestion de l’alimentation NDIS.

Les pilotes clients définissent leurs fonctionnalités de déchargement de protocole à faible consommation d’énergie en appelant les méthodes suivantes appropriées pour leur matériel :

Fonctionnalités de réveil

Les pilotes clients appellent l’une des méthodes suivantes pour définir les fonctionnalités de veille prises en charge par leur matériel lorsque l’appareil est dans un état de faible consommation (Dx) :

Consommation d’énergie et latence de reprise

Lorsque l’appareil réseau est en Dx, il consomme toujours de l’énergie pour effectuer le déchargement et le bras pour le wake. Une fois que l’appareil a lancé la mise en éveil à partir de Dx, il y a un délai avant que l’appareil puisse transférer à nouveau les paquets. Plus l’état d’alimentation interne de l’appareil est profond, moins il consomme d’énergie dans Dx, mais plus la latence de reprise est longue.

Le tableau suivant décrit les recommandations générales concernant le compromis entre la consommation d’énergie et la latence de reprise pour chaque capacité de sortie de veille.

Important

Certaines informations concernent les produits pré-publiés qui peuvent être considérablement modifiés avant leur commercialisation. Microsoft n’offre aucune garantie, expresse ou implicite, concernant les informations fournies. Pour plus d’informations sur un type d’appareil spécifique, reportez-vous à la documentation spécifique au support et au Programme de compatibilité matérielle Windows (WHCP).

Fonctionnalité d’éveil Événements d’éveil Consommation énergétique Reprendre la latence
PacketFilter Tout paquet correspond à la configuration de ReceivePacketFilter Doit être inférieur à dans D0, et l’appareil doit être conservé dans un état approprié afin que la latence de reprise soit très faible <= 10 ms
Bitmap Tout paquet correspond au modèle bitmap configuré Doit être inférieur à celui de l’arme pour PacketFilter, car il a plus de latitude dans la latence de reprise <= 300 ms
MagicPacket Paquet magique Similaire à Bitmap <= 300 ms
MediaChange Média connecté ou déconnecté Similaire à Bitmap <= 300 ms

L’exemple suivant illustre comment un pilote client peut initialiser ses fonctionnalités d’alimentation. Il le fait lors du démarrage de l’adaptateur net, mais avant d’appeler NetAdapterStart. Dans cet exemple, le pilote client définit ses fonctionnalités de bitmap, de modification de média et de sortie de veille du filtre de paquets.

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

Le client peut éventuellement inscrire EVT_NET_DEVICE_PREVIEW_POWER_OFFLOAD et EVT_NET_DEVICE_PREVIEW_WAKE_SOURCE fonctions de rappel pour accepter ou rejeter les déchargements de protocole entrants et les modèles de éveil.

Modèles de déchargement et de sortie de veille du protocole de programmation

Pendant la séquence d’arrêt de mise sous tension de l’appareil, le pilote effectue une itération au sein des modèles de sortie de veille activés et des décharges d’alimentation du protocole, puis les programme dans le matériel. Le pilote effectue cette opération dans ses fonctions de rappel EvtDeviceArmWakeFromS0 et EvtDeviceArmWakeFromSx .

L’exemple suivant montre comment un pilote client peut itérer sur la liste des modèles de sortie de veille pour case activée pour une sortie de veille lors d’une entrée de paquet magique, puis itérer sur la liste de déchargement d’alimentation pour traiter le déchargement du protocole 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;
}

Sur le chemin du retour vers une puissance élevée , le pilote désactive normalement les décharges d’alimentation et les modèles de sortie de veille précédemment programmés dans les rappels EvtDeviceDisarmWakeFromSx et EvtDeviceDisarmWakeFromS0 correspondants.

Raison de l’éveil du rapport

Important

Il est obligatoire que les pilotes clients signalent une raison de sortie de veille à NetAdapterCx.

Lorsque le matériel de carte réseau est mis en éveil du système, le pilote client doit signaler à NetAdapterCx la source de sortie de veille qui a déclenché le wake. Pour la plupart des sources de sortie de veille, les pilotes utilisent la structure NET_ADAPTER_WAKE_REASON_PACKET pour décrire le paquet réseau qui a déclenché la sortie de veille.

Si le NET_WAKE_SOURCE_TYPE est :

Scénarios de gestion de l’alimentation pour le système de secours moderne

Important

Pour la plateforme de secours moderne, le pilote de périphérique réseau doit :

Reportez-vous à la documentation spécifique au média et à WHCP pour connaître les exigences complètes de la veille moderne pour votre type d’appareil.

Le système d’exploitation est responsable des décisions relatives à la stratégie d’alimentation des appareils de mise en réseau. Par exemple, le système d’exploitation contrôle quand un appareil doit accéder à Dx et quels types d’événements réseau l’appareil doit se réveiller. La responsabilité du pilote de périphérique est d’exécuter de manière fiable la séquence de transition d’alimentation lorsque le système d’exploitation le demande, puis de programmer correctement son matériel pour la condition de veille définie par le système d’exploitation.

Le système d’exploitation prend des décisions de stratégie d’alimentation basées sur un large ensemble de facteurs, notamment les stratégies d’alimentation à l’échelle du système et les choix des utilisateurs. Voici quelques stratégies d’alimentation courantes utilisées pour les appareils réseau sur un système de secours moderne :

Important

Ces stratégies d’alimentation peuvent changer avec les mises à jour du système d’exploitation et les informations suivantes sont fournies à titre d’exemple. Les dépendances sur un comportement de bout en bout spécifique du système d’exploitation doivent être évitées.

  • Lorsque l’écran du PC est allumé et que l’appareil réseau est en mode veille, le système d’exploitation demande à l’appareil d’accéder à Dx et de l’armer pour PacketFilter et MediaChange wake.

  • Lorsque le PC entre en veille moderne et que l’appareil réseau est au repos, le système d’exploitation demande à la carte réseau d’accéder à Dx et de l’armer pour Bitmap, MediaChange et Magic Packet wake.

  • Lorsque le PC passe à la mise en veille prolongée, le système d’exploitation demande à la carte réseau d’accéder à Dx et l’arme pour magic packet wake.

Remarque : les pilotes clients NetAdapterCx contrôlent la visibilité de l’onglet gestion de l’alimentation. Pour plus d’informations, consultez Contrôle utilisateur du comportement d’inactivité et de veille des appareils.