NDIS_STATUS
MacSend(
IN NDIS_HANDLE MacBindingHandle,
IN PNDIS_PACKET Packet
);
MacSend is called when a protocol driver calls NdisSend.
MacSend can return the following status codes:
NDIS_STATUS_FAILURE
NDIS_STATUS_INVALID_PACKET
NDIS_STATUS_NOT_ACCEPTED
NDIS_STATUS_NOT_COPIED
NDIS_STATUS_NOT_RECOGNIZED
NDIS_STATUS_PENDING
NDIS_STATUS_REQUEST_ABORTED
NDIS_STATUS_RESET_IN_PROGRESS
NDIS_STATUS_SUCCESS
NDIS_STATUS_UNAUTHORIZED
NdisSend instructs the NIC driver to send a packet through its NIC over the network. When the protocol driver provides a packet to NdisSend, it transfers ownership of both the packet descriptor and the packet data to MacSend.
MacSend configures the packet for transmission to the NIC in the same way as the packet data is configured. The overlying protocol driver determines packet requirements, based on the medium type of the underlying NIC driver. The only exception is padding, which the NIC driver can provide for any packet that is shorter than the minimum for the NIC medium. If MacSend pads a packet, it must explicitly initialize the padding to a known value, such as a blank.
A protocol driver (and higher-level network software components) should not create buffer descriptor chains that are unnecessarily long. However, there is no defined limit on the number of buffer descriptors an NDIS protocol driver can chain to form a packet descriptor. Consequently, MacSend must be capable of handling arbitrarily long chains. To handle a large number of buffers efficiently, MacSend can copy overly fragmented packets into contiguous storage before it transmits them as a block send on the network medium.
MacSend should always process incoming requests in FIFO order. Reordering packets to be transmitted can severely degrade performance in some protocol drivers.
A full-NIC driver must provide software loopback if its NIC does not support loopback. If a packet is received locally as if transmitted from another station (in other words, self-directed), the NIC driver must indicate the appropriate receive events locally. The driver also must determine whether such a self-directed packet actually has to go out on the medium.
MacSend completes synchronously if it finishes the send operation before it returns control with a status code other than NDIS_STATUS_PENDING. At this point, the protocol driver regains ownership of the packet.
If MacSend cannot complete the transmission before it returns control, it returns NDIS_STATUS_PENDING. MacSend usually queues such a packet internally. For asynchronous sends, the NIC driver eventually calls NdisCompleteSend, which, in turn, calls the ProtocolSendComplete function of the driver that initiated the transmit operation. This asynchronous completion allows protocol postprocessing of the send request. When NdisCompleteSend is called, the protocol driver regains ownership of the packet.
MacSend runs at IRQL DISPATCH_LEVEL.
MiniportSend, MiniportSendPackets, MiniportWanSend, NdisCompleteSend, NdisSend, ProtocolSendComplete