Managing Hardware Offload OID Requests to Physical Network Adapters

This topic discusses how a Hyper-V extensible switch forwarding extension manages object identifier (OID) requests for hardware offload technologies on underlying physical adapters over the extensible switch control path.

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.

The following figure shows an example of an extensible switch team for NDIS 6.40 (Windows Server 2012 R2) and later.

The following figure shows an example of an extensible switch team for NDIS 6.30 (Windows Server 2012).

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

By handling the OID request of OID_SWITCH_NIC_REQUEST, a forwarding extension can participate in the configuration of the extensible switch team for hardware offloads. For example, if the extension manages the physical network adapters of an extensible switch team, it can forward the OID_SWITCH_NIC_REQUEST request to a physical adapter that supports the hardware offload.

NDIS and overlying protocol and filter drivers can issue OID requests for hardware offload technologies to the underlying physical network adapter. When these OID requests arrive at the extensible switch interface, it encapsulates the OID request inside an NDIS_SWITCH_NIC_OID_REQUEST. Then, the protocol edge of the extensible switch issues an OID request of OID_SWITCH_NIC_REQUEST that contains this structure.

The extensible switch interface encapsulates OIDs for the following hardware offload technologies:

Internet Protocol security (IPsec) offload (version 2)
The following IPsec OID requests are encapsulated:

• OID_TCP_TASK_IPSEC_OFFLOAD_V2_ADD_SA

• OID_TCP_TASK_IPSEC_OFFLOAD_V2_ADD_SA_EX

• OID_TCP_TASK_IPSEC_OFFLOAD_V2_DELETE_SA

• OID_TCP_TASK_IPSEC_OFFLOAD_V2_UPDATE_SA

The forwarding extension must not fail, or veto, these OID requests.

For more information about version 2 of the IPsec hardware offload technology, see IPsec Offload Version 2.

Single root I/O virtualization (SR-IOV)
The following SR-IOV OID requests are encapsulated:

• OID_NIC_SWITCH_ALLOCATE_VF

• OID_NIC_SWITCH_CREATE_VPORT

• OID_NIC_SWITCH_DELETE_VPORT

• OID_NIC_SWITCH_FREE_VF

• OID_RECEIVE_FILTER_CLEAR_FILTER

• OID_RECEIVE_FILTER_MOVE_FILTER

The forwarding extension can veto OID requests of OID_NIC_SWITCH_ALLOCATE_VF and OID_NIC_SWITCH_CREATE_VPORT by completing the request with a status code other than NDIS_STATUS_SUCCESS. However, the extension must not veto the other SR-IOV OID requests.

For more information about the SR-IOV hardware offload technology, see Single Root I/O Virtualization (SR-IOV).

Virtualized machine queue (VMQ)
The following VMQ OID requests are encapsulated:

• OID_RECEIVE_FILTER_ALLOCATE_QUEUE

• OID_RECEIVE_FILTER_CLEAR_FILTER

• OID_RECEIVE_FILTER_FREE_QUEUE

• OID_RECEIVE_FILTER_QUEUE_ALLOCATION_COMPLETE

• OID_RECEIVE_FILTER_SET_FILTER

The forwarding extension can veto OID requests of OID_RECEIVE_FILTER_ALLOCATE_QUEUE and OID_RECEIVE_FILTER_SET_FILTER by completing the request with a status code other than NDIS_STATUS_SUCCESS. However, the extension must not veto the other VMQ OID requests.

For more information about the VMQ hardware offload technology, see Virtual Machine Queue (VMQ).

The forwarding extension must follow these guidelines for handling hardware offload OID requests:

• The Microsoft IM platform advertises only the common offload capabilities for the overall team. However, the extension can generate OID requests to query the capabilities of each adapter in the team.

  Once the extension has determined the hardware capabilities of the physical adapters in the team, it can forward OID set requests for hardware offloads to an adapter that is best suited for the offload.

• All hardware offload OID requests that are originated by overlying protocol or filter drivers will be encapsulated within a NDIS_SWITCH_NIC_OID_REQUEST structure. All hardware offload OID requests that are originated by the forwarding extension must also be encapsulated in an NDIS_SWITCH_NIC_OID_REQUEST structure.

  The extension forwards the encapsulated OID request to an underlying physical network adapter through an OID set request of OID_SWITCH_NIC_REQUEST. For more information on this procedure, see Forwarding OID Requests to Physical Network Adapters.

• The extension must not modify or fail hardware offload OID requests to clear, free, or complete the allocation of offload resources. For example, the extension must not fail OID requests of OID_RECEIVE_FILTER_CLEAR_FILTER or OID_NIC_SWITCH_DELETE_VPORT. The extensible switch interface must handle these OID requests to clean up state information for these resources.

  The extension can modify or fail hardware offload OID requests to allocate, move, or set offload resources. For example, the extension can fail or modify OID requests of OID_NIC_SWITCH_ALLOCATE_VF or OID_TCP_TASK_IPSEC_OFFLOAD_V2_ADD_SA.

• The extension can originate any hardware offload OIDs to an underlying physical network adapter. However, the extension must not originate a hardware offload OID that clears or frees offload resources that the extension did not allocate.

  For example, the extension must not originate a hardware offload OID request of OID_RECEIVE_FILTER_FREE_QUEUE if it did not originate an OID_RECEIVE_FILTER_ALLOCATE_QUEUE request for the same queue.

  Note  The extension can only originate its own encapsulated hardware offload OID request if it is filtering the same OID request that was issued by overlying drivers. In this case, the extension must not forward the original OID request. Instead, the extension must call NdisFOidRequestComplete to complete this request when NDIS calls its FilterOidRequestComplete to complete the originated OID request.

• If the extension is forwarding a hardware offload OID request to an underlying physical network adapter, the DestinationNicIndex member of the NDIS_SWITCH_NIC_OID_REQUEST structure must be set to the nonzero index value of the adapter. For more information on these index values, see Network Adapter Index Values.

  Also, the DestinationPortId member must be set to the identifier of the extensible switch port to which the external network adapter is connected.

• If the extension is originating a hardware offload OID request to allocate resources for a Hyper-V child partition, the SourcePortId member of the NDIS_SWITCH_NIC_OID_REQUEST structure must be set to the identifier of the extensible switch port to which the partition is connected.

  The SourceNicIndex member must be set to NDIS_SWITCH_DEFAULT_NIC_INDEX.

• When the extension calls NdisFOidRequest to forward the OID request, it must set the OidRequest parameter to a pointer to an NDIS_OID_REQUEST structure for an OID_SWITCH_NIC_REQUEST OID request.

For more information on how the extension filters OID requests, see Filtering OID Requests in an NDIS Filter Driver.

For more information on MUX drivers, see NDIS MUX Intermediate Drivers.