Single-Packet Sends from Connectionless Miniport Drivers (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.

For a single packet send, a connectionless miniport driver declares the following function:

NDIS_STATUS
 MiniportSend(
 IN NDIS_HANDLE MiniportAdapterContext,
 IN PNDIS_PACKET Packet,
 IN UINT Flags
 );

The Flagsparameter is defined by cooperating protocol drivers and miniport drivers; NDIS does not define or make any assumptions about this parameter. However, NDIS provides a function, NdisGetPacketFlags, that is called by the miniport driver to retrieve the flag values. The miniport driver retains the packet until the send completes.

A miniport driver is not required to check the packet size; rather, the miniport driver should assume that a protocol driver will never send a packet that is too large. The protocol driver queries the miniport driver during initialization to determine the maximum packet size it supports. The protocol is responsible for passing only packets of a size supported by the miniport driver.

If a miniport driver can complete the send immediately, it returns NDIS_STATUS_SUCCESS, NDIS_STATUS_FAILURE if the send failed for any reason, such as a miniport driver-determined failure status, and then relinquishes ownership of the packet back to the sender. The miniport driver always returns the send status as the status of MiniportSend; it never sets the Statusmember of the OOB data block for such a packet. The following diagram illustrates a single-packet send when the miniport driver can complete the send immediately.

If a miniport driver cannot complete the send immediately, it returns NDIS_STATUS_PENDING. In this case, the miniport driver retains ownership of the packet until the send completes. For example, the miniport driver might have queued the packet internally or started but not completed the send before returning a pending status. When the send completes, the miniport driver must call NdisMSendComplete, passing a pointer to the packet descriptor that has been sent and relinquishing ownership of the packet resources back to the sender for reuse or to be freed. The following diagram illustrates a single-packet send when the miniport driver cannot complete the send immediately.

How Serialized Miniports Handle a Resource Problem (NDIS 5.1)

If a serialized miniport driver lacks the resources for a send, it can return NDIS_STATUS_RESOURCES. In such a case, NDIS queues the packet and resends it to MiniportSendwhen the miniport driver calls NdisMSendResourcesAvailableor NdisMSendCompleteto indicate that it can now accept packets.

How Deserialized Miniport Drivers Handle a Resource Problem (NDIS 5.1)

If a deserialized miniport driver lacks the resources for a send, it must queue the packet internally and return NDIS_STATUS_PENDING. A deserialized miniport driver cannot return NDIS_STATUS_RESOURCES. The return of such a status would effectively fail the send operation requested by the protocol, resulting in NDIS returning the packet descriptor and all associated resources to the protocol that originally allocated it. The following diagram illustrates a single-packet send when miniport driver lacks the resources for a send.

Rather than relying on NDIS to queue and resubmit send packets whenever MiniportSendlacks the resources to transmit a packet, a deserialized miniport driver manages its own internal packet queuing. The miniport driver is responsible for holding incoming send packets in its internal queue until they can be transmitted over the network.

 

 

Send comments about this topic to Microsoft