Reusing an NDIS_MINIPORT_OFFLOAD_BLOCK_LIST Structure

  • Article

[The TCP chimney offload feature is deprecated and should not be used.]

When propagating a state-manipulation operation, an intermediate driver overlays most of the members of an incoming NDIS_MINIPORT_OFFLOAD_BLOCK_LIST structure onto an NDIS_PROTOCOL_OFFLOAD_BLOCK_LIST structure. (For a comparison of these structures, see Comparison of Offload Block List Types.)

The intermediate driver must also store the ImReserved and SourceHandle members of the NDIS_MINIPORT_OFFLOAD_BLOCK_LIST structure, as shown in the following figure.

diagram illustrating storing the imreserved and sourcehandle members

After its MiniportXxxOffload function is called, the intermediate driver creates a context, called an IM call entry, for the state-manipulation operation. This context is valid only for the duration of the state-manipulation operation.

The intermediate driver copies the ImReserved and SourceHandle members from the incoming NDIS_MINIPORT_OFFLOAD_BLOCK_LIST structure into its IM call entry. (When completing the state-manipulation operation, the intermediate driver will copy the contents of the stored ImReserved and SourceHandle members into the ImReserved and SourceHandle members of the NDIS_MINIPORT_OFFLOAD_BLOCK_LIST structure that it passes to the NdisMXxxComplete function.)

The intermediate driver writes a pointer into the ImReserved member of the NDIS_MINIPORT_OFFLOAD_BLOCK_LIST structure. This pointer points to the IM call entry. (When completing the state-manipulation operation, the intermediate driver will use this pointer to locate the IM call entry for the state-manipulation operation.)

When calling the NdisXxxOffload function to propagate the operation to the underlying driver, the intermediate driver passes a pointer to the newly constructed NDIS_PROTOCOL_OFFLOAD_BLOCK_LIST structure.