Originating NDIS Status Indications from Physical Network Adapters

This topic discusses the method that is used by an extensible switch forwarding extension to originate NDIS status indications for a network adapter that is connected to the switch. The extension can originate an NDIS status indication for the following types of adapters:

  • One or more underlying physical adapters that are bound to the external network adapter of the extensible switch.

    For example, the external network adapter can be bound to the virtual miniport edge of an NDIS multiplexer (MUX) intermediate driver. The MUX driver is bound to a team of one or more physical networks on the host. This configuration is known as an extensible switch team.

    In this configuration, an extensible switch extension is exposed to every network adapter in the team. This allows the extension to manage the configuration and use of individual network adapters in the team. For example, a forwarding extension can provide support for a load balancing failover (LBFO) solution over the team by forwarding outgoing packets to individual adapters. A forwarding extension that manages an extensible switch team is known as a teaming provider. For more information about teaming providers, see Teaming Provider Extensions.

  • A virtual machine (VM) network adapter that is exposed within a Hyper-V child partition and connected to an extensible switch port.

The following figure shows the Hyper-V extensible switch control path for NDIS status indications from physical and VM network adapters for NDIS 6.40 (Windows Server 2012 R2) and later.

Diagram showing the Hyper-V extensible switch control path for NDIS status indications from physical and VM network adapters for NDIS 6.40 and later.

The following figure shows the Hyper-V extensible switch control path for NDIS status indications from physical and VM network adapters for NDIS 6.30 (Windows Server 2012).

Diagram showing the Hyper-V extensible switch control path for NDIS status indications from physical and VM network adapters for NDIS 6.30.

Note  In the extensible switch interface, NDIS filter drivers are known as extensions and the driver stack is known as the extensible switch driver stack.

A forwarding extension can originate encapsulated hardware offload status indications to overlying drivers in the extensible switch driver stack. This also allows the extension to change the current offload capabilities of the underlying team of physical adapters that are bound to the external network adapter of the extensible switch. When a team of adapters are bound to the external network adapter, only the common capabilities of the team are advertised to NDIS or overlying protocol and filter drivers. The extension can extend the advertised capabilities by originating encapsulated status indications to advertise capabilities that are supported by some adapters in the team. For example, the extension can issue an encapsulated NDIS_STATUS_RECEIVE_FILTER_CURRENT_CAPABILITIES indication to change the currently enabled receive filter capabilities for the entire team.

Note  Only forwarding extensions can originate encapsulated status indications. For more information about this type of extension, see Forwarding Extension.

Typically, the forwarding extension originates encapsulated NDIS status indications to change the advertised hardware offload capabilities of the underlying physical adapter. For example, the extension can originate status indications for the following types of hardware offloads:

  • Internet Protocol security (IPsec).

  • Virtualized machine queue (VMQ).

  • Single root I/O virtualization (SR-IOV).

The forwarding extension can also originate encapsulated NDIS status indications to change the hardware offload resources that are allocated for a Hyper-V child partition. Starting with NDIS 6.30, the extension can issue an encapsulated NDIS_STATUS_SWITCH_PORT_REMOVE_VF indication to remove the binding between a VM network adapter and a PCI Express (PCIe) virtual function (VF). The VF is exposed and supported by an underlying physical network adapter that supports the single root I/O virtualization (SR-IOV) interface.

If the forwarding extension originates an encapsulated NDIS status indication for the hardware offload resources of an underlying physical adapter, it must set the members of the NDIS_SWITCH_NIC_STATUS_INDICATION structure in the following way:

  • The DestinationPortId member must be set to NDIS_SWITCH_DEFAULT_PORT_ID.

  • The DestinationNicIndex member must be set to NDIS_SWITCH_DEFAULT_NIC_INDEX

  • The SourcePortId member must be set to the identifier of the extensible switch port to which the external network adapter is connected.

  • The SourceNicIndex member must be set to NDIS_SWITCH_DEFAULT_NIC_INDEX. This allows the status indication to be interpreted as originating from the entire extensible switch team that is bound to the external network adapter.

    Note  The forwarding extension must also set this member to NDIS_SWITCH_DEFAULT_NIC_INDEX if only a single physical network adapter is bound to the external network adapter.

  • The StatusIndication member must be set to a pointer to an NDIS_STATUS_INDICATION structure. This structure contains the data for the encapsulated NDIS status indication.

If the forwarding extension is originating an NDIS status indication for the hardware offload resources of a Hyper-V child partition, it must set the members of the NDIS_SWITCH_NIC_STATUS_INDICATION structure in the following way:

  • The DestinationPortId and DestinationNicIndex members must be set to the corresponding values of the port and network adapter index for the network connection that is used by the partition.

  • The SourcePortId member must be set to NDIS_SWITCH_DEFAULT_PORT_ID.

  • The SourceNicIndex member must be set to NDIS_SWITCH_DEFAULT_NIC_INDEX.

  • The StatusIndication member must be set to a pointer to an NDIS_STATUS_INDICATION structure. This structure contains the data for the encapsulated NDIS status indication.

When the extension issues the encapsulated NDIS status indication, it must follow these steps:

  1. The extension calls ReferenceSwitchNic to increment a reference counter for the source or destination network adapter connection. This guarantees that the extensible switch interface will not delete the network adapter connection while its reference counter is nonzero.

    When the extension calls ReferenceSwitchNic, it sets the parameters in the following ways:

    • If the forwarding extension is originating an encapsulated NDIS status indication for an underlying physical adapter, it sets the SwitchPortId parameter to the value specified for the SourcePortId member. The extension also sets the SwitchNicIndex parameter to the value specified for the SourceNicIndex member.

    • If the forwarding extension is originating an NDIS status indication for a Hyper-V child partition, it sets the SwitchPortId parameter to the value specified for the DestinationPortId member. The extension also sets the SwitchNicIndex parameter to the value specified for the DestinationNicIndex member.

    Note  If ReferenceSwitchNic does not return NDIS_STATUS_SUCCESS, the encapsulated NDIS status indication cannot be issued.

  2. The extension calls NdisFIndicateStatus to forward the encapsulated status notification.

    Note  If the extension is forwarding a filtered OID request, it must call NdisFIndicateStatus within the context of the call to its FilterStatus function.

  3. After NdisFIndicateStatus returns, the extension calls DereferenceSwitchNic to clear the reference counter for the source or destination network adapter connection. The extension sets the SwitchPortId and SwitchNicIndex parameters to the same values that it used in the call to ReferenceSwitchNic.