Deserialized NDIS 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.
A deserialized NDIS miniport driver serializes the operation of its own MiniportXxx functions and queues internally all incoming send packets rather than relying on NDIS to perform these functions. By doing so, a deserialized miniport driver can achieve significantly better full-duplex performance than a serialized miniport driver.
The deserialized driver model is the default model for NDIS miniport drivers. When writing a new NDIS miniport driver, you should write a deserialized driver. Note that connection-oriented miniport drivers, as well as miniport drivers with a WDM lower edge, must be deserialized.
A deserialized miniport driver must meet the following requirements when interfacing with NDIS:
A deserialized miniport driver must identify itself as such to NDIS during initialization. Its MiniportInitialize function must call NdisMSetAttributesEx with the NDIS_ATTRIBUTE_DESERIALIZE flag set in the AttributeFlags.
A deserialized miniport driver's MiniportSendPackets function cannot synchronously complete a multipacket send. Instead, it must always complete each packet asynchronously with NdisMSendComplete for each packet in the incoming array.
A deserialized miniport driver's MiniportSendPackets function usually ignores the Status member of the NDIS_PACKET_OOB_DATA block, but it can set this member to the same status that it will pass to NdisMSendComplete.
If a deserialized miniport driver cannot immediately transmit incoming send packets, it cannot return the packets to NDIS for requeuing. Instead, the miniport driver must queue them internally until sufficient resources are available to transmit the packets. A deserialized miniport driver's MiniportSend or MiniportSendPackets function cannot return NDIS_STATUS_RESOURCES.
A deserialized miniport driver must not examine the Status of indicated packets on return of NdisMIndicateReceivePacket. Instead, a deserialized miniport driver must save a packet's Status in a local variable before indicating up the packet descriptor. If the miniport driver set the packet's Status to NDIS_STATUS_SUCCESS before indicating up the packet descriptor, the miniport driver must not reclaim the packet descriptor until NDIS subsequently returns the packet descriptor to the miniport driver's MiniportReturnPacket function.
A deserialized miniport driver must meet the following driver-internal requirements:
A deserialized miniport driver must protect its packet queues with spin locks. A deserialized miniport driver must also protect its shared state from simultaneous access by its own MiniportXxx functions. For more information about using spin locks, see Introduction to Spin Locks.
A deserialized miniport driver's MiniportXxx functions can run at IRQL <= DISPATCH_LEVEL. Consequently, the driver writer cannot assume that MiniportXxx functions will be called in the sequence in which they process packets. One MiniportXxx function can preempt another MiniportXxx function that is running at a lower IRQL.
A deserialized miniport driver is responsible for packet-queue management. When the miniport driver experiences a resource problem, it cannot return send packets to NDIS for requeuing. Instead, the miniport driver must queue internally all incoming packets until sufficient resources are available to send the packets.
A deserialized miniport driver that does not support packet priority must transmit each array of packets in the protocol-determined order. That is, the miniport driver must transmit the first packet in the array first, the second packet in the array second, and so forth. The miniport driver cannot reorder the packets in any given array. However, a deserialized miniport driver that supports packet priority (for example, IEEE 802.1p) can reorder packets based on priority information.
Note that a deserialized miniport driver usually transmits packets in protocol-determined order. However, a miniport driver that supports packet priority (for example, IEEE 802.1p) can reorder packets based on priority information.