typedef struct _NDIS_PACKET {
NDIS_PACKET_PRIVATE Private;
union {
struct {
UCHAR MiniportReserved[8];
UCHAR WrapperReserved[8];
};
struct {
UCHAR MacReserved[16];
};
};
UCHAR ProtocolReserved[1];
} NDIS_PACKET, *PNDIS_PACKET, **PPNDIS_PACKET;
NDIS_PACKET defines the packet descriptors with chained buffer descriptors for which pointers are passed to many NdisXxx, MiniportXxx, and ProtocolXxx functions.
NDIS drivers must call NdisAllocatePacket to allocate all packet descriptors they use to indicate receives to higher-level drivers with NdisMIndicateReceivePacket. NDIS drivers must call NdisAllocatePacket to allocate all packet descriptors they use for sends to underlying drivers with NdisSendPackets or NdisSend, as well as packet descriptors they pass to NdisTransferData.
Chained to each packet descriptor are one or more buffer descriptors mapping buffers that contain network packet data, either received or to be transmitted. NIC drivers and intermediate drivers can allocate packet descriptors with, at most, 16 bytes of ProtocolReserved space for receive indications.
Any buffers allocated by lower-level NDIS drivers must be mapped by buffer descriptors that were allocated from buffer pool with NdisAllocateBuffer. Only highest-level Windows NT protocols can use MDLs set up by still higher-level drivers as substitutes for NDIS_BUFFER-type descriptors.
NDIS drivers typically use their respective XxxReserved areas to maintain per-packet state about outstanding transfers. For example, a protocol might store a pointer to a protocol-allocated buffer containing lookahead data, which its ProtocolReceive function has already copied, in the ProtocolReserved area of a packet descriptor that the protocol allocates for a call to NdisTransferData.
A single driver can use the MiniportReserved area and a single driver can use the ProtocolReserved area while a particular packet descriptor is being used in a transfer operation. Consequently, NDIS intermediate drivers, which have both MiniportXxx and ProtocolXxx functions, cannot use these areas in incoming packet descriptors for their own purposes.
Instead, NDIS intermediate drivers must repackage each incoming packet in a fresh packet descriptor before it passes the transfer request down to an underlying driver or up to a higher-level driver.
This strategy ensures that the NDIS intermediate driver and the underlying driver each have a MiniportReserved area to use, that the intermediate driver and overlying protocol each have a ProtocolReserved area to use, and that the intermediate driver has a convenient and economical way to maintain per-packet state information about all current transfers. This also ensures that NDIS has correct information in the Private portion of each packet descriptor.
Drivers that supply and consume out-of-band data on network transfers and drivers that support multipacket receives and/or sends must use the member-specific NDIS_GET/SET_XXX macros or the NDIS_OOB_DATA_FROM_PACKET macro to access the NDIS_PACKET_OOB_DATA block associated with each packet descriptor.
When a protocol driver calls NdisSendPackets or NdisSend with a packet descriptor, it relinquishes ownership of the following until that packet descriptor is returned to its ProtocolSendComplete function:
MiniportSend, MiniportSendPackets, MiniportTransferData, NdisAllocateBuffer, NdisAllocatePacket, NdisChainBufferAtBack, NdisChainBufferAtFront, NdisCopyFromPacketToPacket, NdisFreePacket, NdisGetFirstBufferFromPacket, NdisGetPacketFlags, NdisMSendComplete, NdisMTransferDataComplete, NDIS_PACKET_OOB_DATA, NdisQueryPacket, NdisRecalculatePacketCounts, NdisReinitializePacket, NdisReturnPackets, NdisSend, NdisSendPackets, NdisSetPacketFlags, NdisTransferData, NdisUnchainBufferAtBack, NdisUnchainBufferAtFront, ProtocolReceive, ProtocolReceivePacket, ProtocolSendComplete, ProtocolTransferDataComplete