Multipacket Sends (NDIS 5.1)
Note NDIS 5. x has been deprecated and is superseded by NDIS 6. x. For new NDIS driver development, see Network Drivers Starting with Windows Vista. For information about porting NDIS 5. x drivers to NDIS 6. x, see Porting NDIS 5.x Drivers to NDIS 6.0.
MiniportSendPacketsin a connectionless miniport driver or MiniportCoSendPacketsin a connection-oriented miniport driver receives a pointer to an array of pointer(s) to one or more packets to be sent on the network. The miniport driver must preserve the protocol-determined ordering of packet descriptors incoming to its MiniportCoSendPackets function.
The NIC driver can extract out-of-band (OOB) media-specific and priority information from the packet descriptor using NDIS macros supplied for this purpose. For more information, see Packet Out-of-Band Data.
Multipacket Sends from Serialized Miniport Drivers (NDIS 5.1)
A serialized miniport driver can complete a send operation either synchronously or asynchronously. In its MiniportSendPacketsfunction (if it exports such a function), a serialized miniport driver must set send-completion status in the OOB data for each packet before MiniportSendPacketsreturns. Any such status other than NDIS_STATUS_PENDING indicates that the miniport driver is done with the packet (that is, has completed the send operation synchronously) and is returning ownership of the packet descriptor and its associated resources to the caller for reuse or to be freed. If the miniport driver returns NDIS_STATUS_PENDING in a packet, the driver retains ownership of the packet resources and must call NdisMSendCompletewhen it is done with the packet. For a detailed description of a multipacket send operation from a serialized miniport driver, see Multipacket Sends from Serialized Miniport Drivers.
Multipacket Sends from Deserialized Miniport Drivers (NDIS 5.1)
A deserialized miniport driver's MiniportSendPacketsfunction cannot return NDIS_STATUS_RESOURCES and must always complete sends of each packet asynchronously with a call to NdisMSendComplete. NDIS therefore ignores the send-completion status in the OOB data for packets sent by deserialized miniport drivers. Rather than relying on NDIS to queue and resubmit send packets whenever MiniportSendPacketshas insufficient resources to transmit the given packets, a deserialized miniport driver manages its own internal packet queuing. A deserialized miniport driver is responsible for holding incoming send packets in its internal queue until they can be transmitted over the network. In addition, a deserialized miniport driver must synchronize the execution of its own functions so that MiniportSendPacketscan run concurrently with all other MiniportXxx functions. For more information about deserialized miniport drivers, see Deserialized NDIS Miniport Drivers. For detailed information about multipacket sends from deserialized miniport drivers, see Multipacket Sends from Deserialized Miniport Drivers.
Multipacket Sends by Connection-Oriented Miniport Drivers (NDIS 5.1)
Like a deserialized miniport driver, a connection-oriented miniport driver:
Cannot return NDIS_STATUS_RESOURCES in response to a multipacket send
Does not indicate the send-completion status for each packet in a multipacket send
Must queue internally all send packets passed to it by NDIS
Synchronizes the execution of its own MiniportXxx functions
A connection-oriented miniport driver differs from a connectionless miniport driver, however, in that it uses a MiniportCoSendPacketsand always sends (and also receives) packets on a virtual connection (VC). For detailed information about multipacket sends from connection-oriented miniport drivers, see Multipacket Sends from Connection-Oriented Miniport Drivers.