Storing and Referencing Offloaded State

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

For each offload state object that an offload target offloads from the host stack, the offload target allocates a unique offload context area in which to store the offloaded state object and information about that state object. This context area can be in host memory or NIC memory.

An offload context area must contain the following:

• The offloaded state object

• For a TCP connection state object or a neighbor state object, the handle in the NdisOffloadHandle member of the NDIS_MINIPORT_OFFLOAD_BLOCK_LIST structure that was originally associated with the offloaded state object

The following figure shows the relationship between members of an NDIS_MINIPORT_OFFLOAD_BLOCK_LIST structure and the offload context area into which the offload target offloads the state that is associated with the block list structure.

Each NDIS_MINIPORT_OFFLOAD_BLOCK_LIST structure in the offload state tree that is passed to an offload target's MiniportInitiateOffload function contains a MiniportOffloadContext member. A non-NULL value in the MiniportOffloadContext member points to a memory location into which the offload target writes a PVOID value. This PVOID value references the context structure in which the offload target stores the offloaded state object.

As long as the state remains offloaded, the PVOID value that the offload target supplies remains valid. In subsequent calls to the offload target's MiniportQueryOffload, MiniportUpdateOffload, MiniportInvalidateOffload, or MiniportTerminateOffload function, the host stack can reference this PVOID value by specifying a value in the MiniportOffloadContext member that points to the memory location that contains the PVOID value. Referencing the PVOID value references the offload state in the context area that the PVOID value references.

Each NDIS_MINIPORT_OFFLOAD_BLOCK_LIST structure contains an NdisOffloadHandle member that specifies a handle. The offload target stores this handle in the context area for the offloaded state object. When referencing the offloaded state object in subsequent calls to the NdisTcpOffloadEventHandler or NdisTcpOffloadReceiveHandler functions, the offload target passes in the stored handle as an input parameter.

Although the offload target is not required to store such a handle for a path state object, it should do so anyway. The offload target never references a path state object when it calls an indication function. However, it is possible that a change in the TCP chimney architecture could require the offload target to do so in the future.